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and  core  elements,  the  hot  bench  support  facility,  and  the  demonstration. 
Thus,  recognition  and  appreciation  are  extended  to  AFAL  DAIS  personnel 
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features  which  provide  these  system  characteristics  and  attributes  are 
described. 


The  DAIS  core  elements  along  with  support  hardware  and  software 
were  Integrated  Into  a hot  bench  support  facility.  A representative 
avionics  application  and  real-time  mission  were  performed  to  demonstrate 
the  DAIS  architecture  and  concepts.  This  report  describes  the  DAIS 
architecture  and  core  elements,  and  the  support  facilities  elements  that 
were  Integrated  together  to  perform  the  successful  mission  demonstration. 
The  report  also  describes  how  the  basic  DAIS  attributes  and  features 
facilitated  the  Integration  and  testing  as  well  as  system  adaptability 
and  flexibility  to  a broad  class  of  avionic  applications  and  missions. 
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1.  IMTRODUCTIOtl  AHD  SUMMARY 

■>  >1'  ' ■ * . 

T^e.DIgUal  Avionics  InforMtIon  System  (DAIS)  Is  e system 
architecture- for  avionic  systems  utilizing  digital  technology- to 
reduce  14 fe  cyclo  costs  by  defining  and  developing  modula^r  har^re  and 
software  core  elements  and  standardized  Interfaces  which  can  be  con- 
figured and  applied  to  many  aircraft. 

The  DAIS  approach  reflects  a total  system  concept  rather  than 
a functional  subsystem  or  hardware  oriented  system.  For  example,  a 
“Navigation  Subsystem"  In  DAIS  does  not  refer  to  a dedicated  set  of 
hardware  and  software  which  perform  only  the  navigation  function.  DAIS 
architecture  and  elements  are  not  dedicated  to  any  one  avionic  function, 
but  are  used  to  perform  and  Integrate  the  functions  associated  with  the 
avionic  sensors  and  subsystems. 

The  basic  architecture  is  designed  for  a broad  class  of  con- 
figurations where  the  number  of  processors,  for  example,  can  be  reduced 
or  enlarged  depending  upon  the  avionics  and  mission  requirements.  Stan- 
dardization, modularity,  and  application  independent  executive  software 
allows  adaptability  of  this  architecture  to  a broad  class  of  different 
applications  as  well  as  making  misslon-to-misslon  changes  In  a particular 
a1 rcraf t. 


The  DAIS  architecture  consists  of  processors  communicating 
with  each  other  and  the  other  system  elements  (sensors,  weapons,  and 
controls  and  dlspH.s)  through  a standardized  multiplex  data  bus.  This 
standardized  multiplex  data  bus  provides  dual  redundant  information 
paths  between  the  system  resources  (each  computer  and  other  system 
elements).  Centralized  system  single-point  control  is  performed  by  a 
processor  resident  software  executive  that  can  be  relocated  for  redun- 
dancy. Application  software  Is  structured  to  provide  modularity, 
reliability,  and  transferability.  This  system  architecture  is  flexible 
to  accommodate  a wide  variety  of  avionics  configurations,  missions,  and 
sensors;  and  provides  redundancy  to  Improve  availability,  and  accommodate 
changes  in  technology. 

The  basic  elements  of  the  DAIS  architecture  which  can  be 
restructured  for  various  aircraft  avionic  configurations  are  called 
DAIS  core  elements  (or  building  blocks)  and  are  composed  of  the  DAIS 
multiplex,  DAIS  processors  (with  associated  memory),  DAIS  mission  soft- 
ware, and  DAIS  controls  and  displays.  Additional  elements  are  the 
support  software  elements,  namely  the  JOVIAL  Compiler,  Software  Design 
and  Verification  System  (SDVS)  and  Partitioning,  Analyzing  and  Linkage 
Editing  Facility  (PALEFAC).  Sensors,  weapons,  and  other  subsystems  are 
selected  as  required  for  the  particular  mission  and  connected  to  the 
Interface  modules  of  the  Remote  Terminals  or  directly  to  the  multiplex 
data  bus. 


The  DAIS  core  elements  along  with  support  hardware  and  soft- 
ware were  Integrated  Into  a hot  bench  support  facility.  A real-time 
mission  was  performed  to  demonstrate  the  DAIS  architecture  and  concepts. 
This  report  describes  the  DAIS  architecture  and  core  elements,  and 
the  support  facilities  elements  that  were  integrated  together  and  tested 
to  perform  the  successful  mission  demonstration. 
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2.  . BACKGROUND 

! The  Digital  Avionics  Information  System  (DAIS)  has  been  under 
development  by  the  Air  Force  since  1973.  DAIS  provides  a system  archl*^ 
tecture  which  can  adapt  currently  available  avionics  subsystems  and 
sensors  to  a common,  modularly  expandable  avionics  core.  The  architecture 
of  DAIS  also  provides  a general  system  framework  to  design  future  avionics 
systems.  , 

The  classical  approach  to  avionics  system  design  has  provided 
a system  unique  to  each  particular  aircraft.  Avionics  systems  tend  to 
be  snapshots  of  technology  available  at  the  time  of  development  with 
little  or  no  relationship  to  previous  work.  The  result  of  this  approach 
Is  that  aircraft  which  are  part  of  the  operational  fleet  at  a given 
point  In  time  have  neither  commonality  of  hardware  or  software,  nor  apy 
sort  of  compatibility. 

The  effect  of  the  lack  of  commonallty/compatiblllty  Is  felt 
In  cost  and  reliability  of  the  newly  developed  weapon  system  or  upgraded/ 
retrofit  efforts.  Since  new  hardware  and  software  developments  are  re- 
quired, additional  front  end  design  costs  are  Incurred.  The  most  serious 
effect,  however.  Is  the  maintenance  cost.  Different  hardware  across  the 
fleet  compounds  the  problems  of  spares  provisioning  and  repair,  personnel 
training,  and  maintenance  support.  These  factors  contribute  to  the  high 
cost  of  ownership  for  avionics. 

In  addition,  since  avionic  procurements  are  relatively  small 
lots,  hardware  production  maturity  Is  rarely  reached.  This  results  In 
hardware  with  lower  MTBF's  than  commercial  counterparts  with  larger 
production  quantities.  Although  software  accomplishes  much  the  same 
function  on  all  military  aircraft,  the  classical  approach  results  In  new 
design  for  each  aircraft  system.  This  generates  a corresponding  problem 
of  software  reliability. 

» 

The  above  problems  are  not  the  only  ones  generated  by  the 
classical  approach.  Perhaps  the  most  serious,  from  an  operational  view- 
point, Is  the  limited  adaptability  of  point  designed  avionic  systems  to 
changing  threat  environments  or  expanded  mission  roles  for  the  weapon* 
system.  Past  experience  has  shown  that  the  airframe  lifetime  Is  sig- 
nificantly longer  than  the  useful  (In  the  sense  of  operational  capability) 
lifetime  of  the  avionics.  Hence,  a typical  weapon  system  1s  modified 
many  times  during  the  life  of  the  airframe. 

The  Digital  Avionics  Information  System  (DAIS)  was  conceived 
as  a means  of  avoiding  the  problems  Inherent  In  the  classical  avionics 
approach.  DAIS^  considers  the  avionics  job  as  a hybrid  of  process  con- 
trol and  Information  management  functions^  and  provides  a system  archi- 
tecture which  Is  Independent  of  the  particular  airframe  and,  to  a -large 
extent,  the  technology  used  to  Implement  the  system. 
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For  example,  tactical  aircraft  accomplish  the  same  generic 
mission  functions  of  navigation,  communication,  stores  management, 
weapon  delivery,  flight  control,  etc.  The  classical  avionics  approach 
has  been  to  physically  partition  the  system  In  accordance  with  the 
functional  partitioning  of  the  mission.  Therefore,  navigation  systems, 
weapon  delivery  systems,  and  flight  control  systems  have  resulted.  Each 
of  these  systems  Is  Independent  of  the  other  and  Is  developed  by  Inde- 
pendent contractors  using  different  designs. 

The  DAIS  approach  views  the  avionics  as  a whole  and  not  as  a 
collection  of  prior  defined  systems.  By  using  this  approach,  common 
functions  of  the  avionics  system  could  be  Identified  which  were  required 
by  each  of  the  mission  functions.  This  resulted  In  an  Integrated  avionics 
system  which  accomplishes  all  of  the  required  mission  functions  but  Is 
partitioned  along  the  lines  of  processing  hardware,  software.  Information 
transfer,  and  display  and  control.  Hence,  a new  partitioning  of  the 
avionics  system  was  defined  so  that  the  mission  functions  could  be  mapped 
onto  that  partitioning. 

The  next  step  was  to  apply  some  constraints  to  the  evolving 
system  architecture.  For  reasons  of  cost  (acquisition  and  especially 
life  cycle),  maximum  utilization  of  common  hardware  was  desired.  If 
common  computers  are  used  In  a multi -computer  system,  development  costs 
can  be  saved,  software  costs  can  be  reduced  (common  code),  and  mainten- 
ance problems  can  be  reduced.  In  order  to  enhance  redundancy,  and  error 
management  and  recovery,  maximum  sharing  of  information  and  maximum  use 
of  shared  resources  were  desired.  This  was  based  on  the  premise  that  if 
the  necessary  information  is  available  system  wide,  the  system  can 
reorient  the  task  of  selected  resources  to  accomplish  critical  mission 
functions  when  primary  resources  have  failed.  One  of  the  few  performance 
Improvement  constraints  was  to  provide  a better  method  of  interfacing  to 
the  pilot.  The  classical  system  forces  the  pilot  to  process  large 
amounts  of  raw  data  as  well  as  make  decisions.  The  DAIS  approach  was  to 
process  data  for  the  pilot  and  aid  his  decision  process,  thereby  reducing 
pilot  workload.  The  final  constraint  was  to  provide  an  open  ended  system 
capability.  The  architecture  chosen  should  be  capable  of  handling  tasks 
larger  than  apy  anticipated  today  and  should  not  depend  upon  today's 
technology.  Such  a system  should  be  able  to  expand  or  change  by  adding 
or  modifying  resources  without  affecting  the  architecture. 

With  the  above  constraints  defined,  the  next  step  was  to 
define  the  system  architecture.  Using  terms  analogous  to  the  computer 
literature  usage,  system  architecture  is  the  way  the  system  appears  to 
the  user  while  the  topology  (organization)  Is  the  way  the  various  sub- 
systems are  Interconnected  logically  and  physically  to  form  the  system. 
The  topology  chosen  for  DAIS  was  that  of  a distributed  system.  This 
allowed  physically  distributing  the  resources  to  enhance  survivability 
and  provided  a means  for  expanding  system  capability  without  regard  to 
physical  placement  of  the  resources  required  to  expand  the  capability. 

The  architecture  provides  a hlerarchlal  system  structure  operating 
under  centralized  control.  To  the  "user",  therefore,  DAIS  appears  as  a 
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centralized  system.  The  Implementation  of  DAIS  required  the  develop- 
ment of  certain  "building  blocks"  to  achieve  the  design  goals.  These 
building  blocks  are  called  the  DAIS  core  elements  and  consist  generically 
of  processors,  multiplex  Information  transfer,  control  and  display  and 
the  software  associated  with  the  flight  processors.  The  Interfaces  to 
the  external  world  are  through  the  sensors/subsystems  and  are  Interfaced 
to  the  core  elements  to  make  a complete  system. 

The  DAIS  concept,  therefore,  proposes  that  the'processing. 
Information  transfer,  control  and  display  functions  be  common  and 
service  the  avionics  functional  areas  on  an  Integrated  basis.  Thus, 
the  DAIS  approach  reflects  a total  system  concept  rather  than  a func- 
tional subsystem  or  hardware  oriented  system. 

AFAL  Initiated  the  DAIS  program  In  1973  with  two  separate 
contracts  to  Texas  Instruments  (F33615-73-C-1156)  and  General  Dynamics 
(F33615-73-C-1244)  to  define  and  provide  the  guidelines  for  the  design 
of  the  DAIS  system.  Following  these  studies,  contracts  to  The  Boeing 
Company  (F33615-74-C-1108)  and  Texas  Instruments  (F33615-74-C-1023) 
were  let  to  provide  the  Initial  hardware  and  software  specifications 
for  the  DAIS  core  elements,  and  Initial  system  designs  for  DAIS. 

Subsequent  to  these  studies,  AFAL  let  contracts  to  design 
and  develop  the  core  elements  as  shown  below: 


Multiplex  Equipment 
Processor 
Mission  Software 
Controls  & Displays 


IBM 

Westinghouse 
Intermetrl cs 
Hughes 


Also,  AFAL  let  a System  Integration  and  Test  Coordination  (SITC) 
contract  with  TRW  Defense  and  Space  Systems  to  support  AFAL  In  combining 
these  core  elements,  along  with  support  hardware  and  software  Into  an 
Integrated  hot  bench.  The  hot  bench  would  have  the  capability  to  simu- 
late close  air  support  missions  In  real  time  to  evaluate  and  demonstrate 
the  DAIS  technology. 


The  Initial  part  of  the  SITC  effort  was  the  development  and 
demonstration  of  the  Hardware  Architecture  Simulation,  a DAIS  prototype, 
to  Investigate  and  verify  the  DAIS  architecture,  and  gain  technical 
experience  which  was  directly  transferable  to  the  full  DAIS  development 
effort.  This  effort  Is  described  In  Section  8.0  of  this  report. 
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DAIS  SYSTEM  ARCHITECTURE 


DAIS  Is  a system  architecture  which  can  be  configured  for 
various  avionic  applications  and  missions  using  core  elements  or 
building  blocks.  The  purpose  of  the  DAIS  concept  Is  to  reduce  the 
proliferation  and  non-standardization  of  aircraft  avionics,  and  permit 
the  Air  Force  to  assume  Initiative  In  the  specification  of  standard 
avionic  systems  and  Interfaces  for  future  Air  Force  system  acquisitions. 

Historically,  avionic  systems  have  been  established  along 
semi -autonomous  functional  areas  such  as  navigation,  weapon  delivery, 
stores  management,  flight  control,  cotnnunl cations,  etc.  Each  of  these 
functional  areas  would  have  a digital  system  with  Its  own  processing. 
Information  transfer,  control  Inputs,  and  display  set.  There  has  been 
an  Interface  between  each  functional  area  only  as  necessary  for  Inter- 
action purposes,  using  non-standard  Interfaces.  The  DAIS  concept  pro- 
poses that  the  processing.  Information  transfer,  control  and  display 
functions  be  common  and  service  all  the  previously  described  functional 
areas  on  an  Integrated  basis  as  shown  In  Figure  1. 

The  general  objectives  of  the  DAIS  architectural  design  are 
listed  In  Table  1 along  with  the  design  considerations  or  attributes 
to  help  satisfy  the  objectives.  These  attributes  such  as  standardiza- 
tion, redundancy,  modularity,  on-board  test,  etc.,  have  been  designed 
Into  the  system  at  the  start  of  the  design  as  opposed  to  incorporation 
at  a later  stage. 


DAIS  CORE  ELEMENTS 


TABLE  1.  DESIGN  CONSIDERATIONS  UTILIZED  IN  MEETING  DAIS  OBJECTIVES 


3,1  System  Configuration 

A block  diagram  of  the  DAIS  architecture  and  core  elements 
or  building  blocks  Is  shown  In  Figure  2.  These  hardware  core  elements 
are  the  processors  (with  associated  memory),  the  multiplex  system  (Bus 
Controllers,  Remote  Terminals,  and  Data  Bus),  and  the  controls  and 
displays  (pilot  Interface).  Additional  core  elements  are  the  mission 
software  or  Operational  Flight  Program  (OFP),  and  the  Operational  Test 
Program  (OTP).  There  Is  also  a set  of  non-real  time  support  software, 
tools,  namely  the  JOVIAL  (J73/I)  Compiler,  the  Software  Design  and 
Verification  System  (SDVS),  and  the  Partitioning  Analyzing  and  Linkage 
Editing  Facility  (PALEFAC). 

The  DAIS  architecture  as  shown  In  Figure  2 consists  of  proces- 
sors that  coinnunicate  with  each  other  and  with  the  sensors,  weapons, 
controls,  and  dlspla^ys  through  a dual  redundant  standardized  (MIL-STD- 
1553A)  multiplex  data  bus  system  under  control  of  mission  software.  The 
mission  software  as  shown  In  Figure  2 consists  of  application  software, 
which  performs  the  processing  required  for  a specific  aircraft  mission 
application  and  sensor/subsystems,  and  the  executive  software,  which 
performs  the  system  control  and  provides  services  to  the  application 
software.  The  executive  software  consists  of  the  master  executive,  local 
executive,  and  backup  master  executive  (if  required).  The  master  exec- 
utive is  responsible  for  the  system  control  and  resides  in  the  processor 
designated  the  master  processor.  The  local  executive  is  located  in  each 
processor  and  provides  the  real  time  services,  including  data  read  and 
write,  and  task  control  to  the  application  software.  The  master  execu- 
tive can  also  reside  In  a processor  designated  monitor,  and  provides  a 
backup  to  the  master  executive.  The  executives  are  table  driven  to  pro- 
vide flexibility  to  accommodate  various  avionic  configurations.  The 
mission  software  is  implemented  in  the  JOVIAL  J73/I  higher  order  language 
utilizing  structured  programming  techniques,  standards,  and  modular 
architecture  approach  to  provide  reliable,  reusable,  and  maintainable 
mission  software. 

Centralized  single  point  system  control  Is  performed  by  only 
one  processor,  at  any  one  time,  and  Its  associated  Bus  Control  Interface 
Unit  (BCIU),  which  Is  designated  the  master  (Figure  2).  In  this  control 
mode,  the  master  processor/bus  controller,  under  control  of  the  master 
executive.  Issues  commands  to  other  devices  on  the  selected  data  bus, 
participates  In  data  transfers  on  the  bus  If  required,  checks  status 
response  from  the  addressed  devices  and  Interprets  anomalies  for  all  bus 
traffic.  Remote  mode  Is  the  operational  state  assigned  to  those  proces- 
sors and  bus  controllers  which  are  not  directed  to  be  master.  Remote 
mode  functions  Include  monitoring  of  the  multiplex  bus  for  connands 
directed  to  that  address,  responding  with  an  appropriate  status  word,  and 
storing  or  fetching  bus  data  (If  required).  Terminals  respond  with  the 
Identical  protocol  as  remote  processors/BCIUs.  If  required  for  system 
redundancy,  a processor/BCIU  designated  the  monitor  can  be  Included  In 
the  architecture.  The  monitor  processor,  during  normal  system  operation, 
responds  as  In  the  remote  mode.  The  monitor  contains  the  backup  master 
executive,  which  Is  Invoked  during  system  failure  modes  that  require 
backup  operation. 
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FIGURE  2.  DAIS  SYSTEM  ARCHITECTURE 


The  Remote  Terminals  (RT)  conditions  via  the  interface  modules 
various  analog,  digital  and  discrete  signals  from  the  sensors/subsystems 
and  formats  these  for  bus  transmission.  The  RT  is  designed  to  accom- 
modate, interchangeably,  various  types  of  interface  modules  to  provide 
the  proper  electrical  interface  with  different  sensors,  and  is  program- 
mable to  permit  mapping  of  the  data  between  the  data  bus  and  the  sensors 
as  required  for  the  specific  avionic  system  configuration.  The  avionic 
sensors  or  subsystems  can  interface  directly  with  the  data  bus  if  the 
subsystem  is  compatible  with  the  bus  control  protocol.  ; 

The  DAIS  system  provides  a set  of  application  "or  mission  inde- 
pendent core  elements  or  building  blocks.  For  a specific  aircraft 
application,  the  system  designer  is  at  liberty,  to  design  or  configure 
these  building  blocks  to  specific  hardware  configuration,  as  shown  in 
Figure  3,  and  software  partitioning  based  upon  avionic  subsystems  and 
mission  requirements  including  reliability  and  availability.  The  support 
software:  J73/I  Compiler,  SDVS,  and  PALEFAC,  provides  the  system 
designer  and  application  programmer  the  tools  to  develop,  test,  and 
partition  the  application  software  and  automatically  generate  the  exec- 
utive tables  for  the  specific  aircraft  configuration. 

It  should  be  clearly  understood  that  the  basic  DAIS  architec- 
ture is  designed  for  a broad  class  of  applications  and  missions.  The 
number  of  processors  can  be  reduced  or  enlarged  depending  upon  the 
avionics  and  mission  requirements.  Application  independent  executive 
software  allows  adaptability  of  this  architecture  to  a broad  class  of 
different  applications  as  well  as  to  making  mission-to-mission  changes 
in  a particular  aircraft.  Sensors,  weapons,  and  other  subsystems  are 
selected  as  required  for  the  particular  mission  and  connected  to  the 
standard  Interface  of  the  remote  terminal  units  of  the  multiplex  system 
or  connected  directly  to  the  data  bus.  Application  modules  of  the  soft- 
ware will  be  selected  or  developed  as  required  by  the  subsystems.  This 
basic  DAIS  architecture  will  reduce  unnecessary  development  duplication 
of  similar  tasks  every  time  new  systems  are  developed. 
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FIGURE  3.  A SYSTEM  CONFIGURATION 


3.2 


DAIS  Core  Elements 


3.2.1  DAIS  Multiplex 

The  DAIS  multiplex  provides  information  transfer  between  the 
elements  within  the  system,  including  DAIS  processors,  controls  and  dis- 
pla^ys,  and  subsystems.  It  consists  of  the  Bus  Controller  Interface  Unit 
(BCIU)  or  integrated  processor/bus  controller.  Remote  Terminal  units 
(RT),  and  the  multiplex  cable  assembly  (data  bus).  The  message  struc- 
ture, data  format,  and  command-response  protocol  is  as  defined  in  MIL- 
STD-1553A.  The  message  format  consists  of  three  types  of  operations 
as  shown  in  Figure  4 and  word  formats  as  shown  in  Figure  5.  The  system 
is  a time  division  multiplex  (TDM)  system  and  a command-response  system 
with  one  processor/BCIU  controlling  the  bus  traffic  at  any  given  time. 
Each  multiplex  cable  assembly  consists  of  a twisted,  shielded  wire  pair 
and  bus  couplers. 

Message  protocol  is  the  sequence  of  bus  messages  required  to 
perform  system  and  bus  control  functions  (synchronous  and  asynchronous 
operations),  and  error  and  failure  management  operations.  A set  of 
system  control  procedures  were  defined  to  describe  the  procedures  to 
perform  these  operations  as  summarized  in  paragraph  4.1. 

a.  Bus  Controller  Interface  Unit  (BCIU).  The  BCIU  provides 
the  interface,  control,  and  data  transfer  functions  between  a processor 
and  two  data  buses.  The  BCIU  operates  under  control  of  the  Executive 
software  in  the  processor  in  either  a remote  mode  or  master  mode. 

In  the  remote  mode,  the  BCIU  provides  transfer  of  data  in 
both  directions  between  the  processor  and  either  of  two  buses  based 
upon  commands  received  from  either  of  the  data  buses,  provides  status 
replies  on  the  appropriate  data  bus  in  response  to  commands,  and  special 
internal  operations,  and  interrupts  the  associated  processor  upon 
receipt  of  certain  mode  commands  on  the  data  buses. 

In  the  master  mode,  the  BCIU  constructs  and  controls  the  bus 
commands  according  to  a two-word  instruction  fetched  from  the  processor 
memory.  These  instruction  words  contain  not  only  transmitting-receiving 
terminal  addresses,  subaddresses,  and  word  count  fields,  but  also  the 
fields  to  dictate  bus  selection,  automatic  retry  options,  and  BCIU 
internal  operation  codes.  < 

The  BCIU  sequentially  interprets  each  instruction  pair  to 
determine  action  required.  Depending  on  the  op-code  contained  in  the 
instruction  pair,  the  BCIU  initiates  a bus  operation,  performs  a no-op 
or  performs  a link  operation.  If  a bus  operation  is  indicated,  the  BCIU 
performs  the  message  transmission  on  the  data  bus,  and  accesses  the  next 
sequential  instruction  pair  when  the  present  operation  is  completed 
successfully.  If  a no-op  is  indicated,  the  BCIU  accesses  the  next 
requested  Instruction  pair.  If  a link  operation  is  indicated,  the  BCIU 
performs  no  bus  operation,  but  uses  the  second  word  of  the  instruction 
as  the  address  of  the  next  instruction  pair. 
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Figure  6 Identifies  the  major  components  that  comprise  a BCIU. 
Each  Multiplex  Terminal  Unit  (MTU)  provides  the  interface  function  to 
one  data  bus.  The  Processor  Interface  Module  (PIH)  provides  the  inter- 
face function  to  the  processor.  The  changing  of  processor  types  Is 
acconmodated  by  a re-des1gn  of  only  the  PIM.  The  Bus  Control  Module 
(BCM)  provides  the  timing,  control.  Instruction  decoding  and  data 
transfer  routing  required  to  Implement  the  various  operation  modes. 

The  BCIU  also  performs  mode  code  operations  to  obtain  status  or  built- 
in-test  Information  for  error  and  failure  analysis,  or  perform  special 
mode  operations  as  defined  In  paragraph  4. 1.2.2. 

b.  Remote  Terminal  (RT).  The  Remote  Terminal  provides  the 
interface  between  the  subsystens  and  the  two  data  buses.  The  RT  trans- 
fers data  in  both  directions  between  the  multiplex  bus  and  subsystem 
via  the  Interface  Modules,  based  upon  commands  received  from  either 
data  buses,  and  provides  status  replies  on  the  appropriate  bus  In  res- 
ponse CO  commands.  The  RT  performs  special  mode  command  operations 
upon  receipt  of  a mode  command. 

The  RT  provides  a modular  and  programmable  design  to  provide 
flexible  partitioning  of  the  data  messages  to  the  appropriate  subsys- 
tems/sensors, and  signal  conditioning  required  by  different  numbers 
and  mixes  of  subsystem  signals.  The  RT  also  provides  dual  redundancy. 

The  RT  is  composed  of  Multiplex  Terminal  Unit  (MTU),  Timing 
and  Control  Unit  (TCU),  and  Interface  Modules  (IM)  as  shown  in  Figure 
7.  The  Multiplex  Terminal  Unit  (MTU)  Interfaces  to  the  data  bus,  and 
transmits  and  receives  Information  between  the  data  bus  and  the  Timing 
and  Control  Unit  (TCU),  under  control  of  the  TCU. 

The  Timing  and  Control  Unit  (TCU)  performs  all  of  the  timing, 
control,  buffering,  decoding  and  checking  required  to  receive  or  trans- 
mit Information  from  the  data  bus  and  transfer  that  Information  as 
outputs  or  Inputs  from  the  RT,  via  the  Interface  Modules  (IM).  The  TCU 
contains  a programmable  device  which  controls  the  mapping  of  each  data 
word  In  each  message  to  the  proper  subsystem  Interface,  I.e. , the 
specific  IM  slot  In  the  RT  and  channel  on  that  IM.  The  Interface 
between  the  TCU  and  IMs  Is  standardized  and  contains  the  signals 
required  to  allow  TCU  to  select  the  Individual  modules.  Therefore,  a11 
IM  slots  accept  all  IM  types. 

Each  RT  will  Interface  with  different  numbers  and  mixes  of 
subsystems/sensors  signals  for  each  specific  system  configuration.  This 
Is  accomplished  by  Inserting  the  proper  number  and  type  of  Interface 
modules  Into  the  IM  slots  In  the  RT  housing  and  appropriate  ROM  program- 
ming In  the  TCU.  Table  2 lists  the  typical  type  of  RT  Interface  Modules 
provided  to  Interface  with  the  subsystems.  If  required,  a special 
Interface  module  can  be  designed  to  Interface  with  an  existing  sii>sys- 
tem  with  a unique  Interface. 
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PROCESSOR 
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FIGURE  6.  BUS  CONTROL  INTERFACE  UNIT 
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HOUSING 


FIGURE  7.  REMOTE  TERMINAL  UNIT 


TABLE  2.  RT  INTERFACE  MODULES 
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The  MTU  4 TCU  functions  of  the  RT  can  be  entedded  In  a sensor 
or  subsystem,  so  that  the  interface  of  the  sensor  or  subsystem  Is  dir- 
ectly with  the  multiplex  data  bus.  Functionally  the  embedded  RT  would 
respond  to  conmands  received  on  either  data  buses  the  same  as  an  RT. 

3.2.2  DAIS  Processors 

The  DAIS  processors  (AN/AYK-15)  provide  computational  and 
control,  memory  and  input/output  capabilities.  The  DAIS  processors  are 
distributed  in  the  architecture,  interconnected  through  the  DAIS 
multiplex  system.  In  this  architecture,  the  processors  address  only 
their  own  memory  units. 

The  DAIS  processors  include  the  following  features: 

• Central  Processor  Unit  (CPU) 
e 16  general  registers 
e Extensive  instruction  repertoire 

• 379K  operations  per  second  throughput  based 
upon  a specified  benchmark  program 

e Floating  point  capability 

e Direct,  indirect,  immediate  and  index 
addressing  modes 

e Programmable  Interval  timers 

e Vectored  interrupts 

e Memory 

• Exapndable  random  access  memory  to  65K  words 
(16  bit  words),  in  16K  word  memory  modules 

e Memory  parity  and  write  protect  features 

e Input  and  Output 

e Discretes 

e Program  controlled 

t Direct  Memory  Access  (DMA)' 

e External  interrupts 
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The  Integrated  DAIS  processor/bus  controller  combines  the  pro- 
cessor and  BCIU  functions  Into  an  Integrated  unit  and  Incorporates  the 
MIL-STD-1750  Instruction  set.  This  Integrated  DAIS  processor/bus  con- 
troller (AN/AYK-15A)  Includes  the  following  features: 

e Processor 

e 16  general  registers 

e Extensive  Instruction  repertoire  as 
specified  In  MIL-STD-1750 

• 379K  operations  per  second  throughput  based 

upon  specified  benchmark  program 

e Floating  point  capability 

e Direct,  Indirect,  Immediate,  base  relative, 

IC  relative,  and  Index  addressing  modes 

e Programmable  Interval  timers 

e Vectored  1 nterrupts 
# Memory 

e Expandable  random  access  memory  to  65K  words 
(16  bits  per  word).  In  16K  word  memory  modules 

t Memory  parity  and  write  protect  features 


e Input  and  Output 
e Discretes 
e Program  controlled 


e Direct  memory  access 


e External  1 nterrupts 


• Multiplex  data  bus 
e Bus  controller 


) 


Added  feature  to  -15A 


3.2.3  DAIS  Controls  and  Displays 

The  DAIS  controls  and  displays  consist  of  a set  of  shared 
multipurpose  data  entry  devices,  control  devices,  and  display  devices 
to  Interface  the  pilot  with  various  avionic  system  configuration.  The 
DAIS  Controls  and  Displays  concept  Is  based  upon  an  Integrated  set  of 
coitMon  and  shared  devices  which  can  be  used  for  most  of  jthe  avionic 
functions.  Thus,  the  DAIS  control  and  display  concept  embodies  the 
following  features: 
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• Flexlbl  Mty  to  accomnodate  changes  fn  avfontc  ) 

functions  and  tnoding  as  a result  of  new  j 

sensors/s ubsys terns  or  mission  changes  without  / 

requiring  a physical  change  In  the  control  j 

and  display  devices.  | 

• Efficient  design  for  centralized  system  manage-  * 

ment  by  the  pilot  as  required  for  the  system 

application. 

t Redundancy  If  required  for  specific  system 
application  (e.g.  CRT's  serve  as  backup  to 
each  other,  redundant  display  generators)  fOr 
backup  of  mission  critical  functions. 

a Provide  for  mode  control  and  command  data  from 
data  entry  devices  and  to  display  devices  to 
be  transmitted  and  received  over  the 
multiplex  bus  from  mission  software. 

The  set  of  control  and  display  equipment  developed  for  the  DAIS 
demonstration  Is  a representation  of  the  architecture  one  would 
utilize  In  the  DAIS  architecture.  An  exairple  of  the  controls  and 
displays  subsystem  configuration  is  shown  in  Figure  8.  The  units  or 
building  blocks  of  the  DAIS  controls  and  displays  Include  the  fol- 
lowing: 

a.  Modular  Programmable  Display  Generator  (MPDG).  The  MPDG 
Is  a programmable  display  graphic  generator,  capable  oT  being  program- 
med to  generate  graphics  composed  of  predefined  symbols,  line  segments, 
and  alphanumeric  symbols.  The  MPDG  generates  symbols  for  presenta- 
tion on  both  raster  and  stroke  written  display  devices.  The  MPDG 
generates  the  display  data  for  up  to  four  raster  display  devices  via 
the  Display  Switch/Memory  Unit  (DS/MU)  which  contains  the  refresh 

memory  for  the  raster  displays.  The  MPDG  also  generates  stroke  (x  and  : 

y deflection  signals,  and  blank/unblank  signals)  for  one  stroke 

display. 

The  MPDG  generates  various  forms  of  symbology  Including 
geographic  map  symbols,  overlay  symbols,  tactical  horizontal  and  ver- 
tical situation  data,  flight  situation  and  director  symbols  as  pro- 
gramned  In  the  C/D  subsystem  application  software.  This  application 
software  executes  on  the  programmable  processor  In  the  MPDG. 

b.  C/D  Subsystem  Application  Software.  The  C/D  subsystem 
application  software  consists  of  the  routines  and  display  lists  for  the 
display  generator  In  the  MPDG  to  generate  the  display  symbology,  text 
formats  and  pages,  map  data,  etc.  required  for  a specific  avionics 
system  application.  Mode  control  and  data  messages  received  from  mission 
software  via  the  multiplex  system  controls  the  display  modes,  display 
assignments,  text  displays,  and  variable  symbology.  The  application 
software  as  commanded  by  mission  software  performs  the  loading  of  the 
MPDG  programs,  text  pages,  and  map  data  from  the  C&D  Mass  Memory  Unit 
(MMU). 
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The  specific  application  software  was  developed  using  an 
NPDG  assembler  hosted  on  a DEC-10  system.  The  source  language  con- 
sists of  the  M’DG  microprocessor  Instructions,  display  generator  com- 
mand formats  and  assembler  directives. 

c.  Display  Swi tch/Memorv  Unit  (K/HU).  The  DS/MU  Is  used 
In  conjunction  with  me  or  two  MPDGs  to  drive  the  raster  display 
devices.  The  DS/MU  accepts  digital  data  from  one  or  two  HPD^;  store 
the  data  In  up  to  six  refresh  memories;  and  reads  the  data  to  up  to 
four  raster  displays  (525  line  or  875  line  format). 

The  raster  displays  are  displayed  alone  or  overlayed  with 
sensor  video.  The  DS/MU  provides  the  capability  to  route  signals  from 
up  to  14  sensor  or  weapon  video  sources  (e.g.  TV  sensor  - 525  line, 

FLIR  sensor  - 875  line,  weapon  station  sensors  - 525  line)  to  any  of 
the  four  raster  displays,  one  external  video  signal  to  a single 
display  at  one  time. 

The  DS/MU  also  accepts  stroke  generated  signals  from  one  Or 
two  MPDGs  and  routes  these  signals  to  one  of  the  two  stroke  displays. 

Since  the  DS/MU  Is  a serial  element  In  the  system,  the  DS/MU  Is 
designed  to  minimize  the  probability  of  a single  failure  within  the 
DS/MU  from  causing  complete  loss  of  display  capability. 

d.  Display  teylces.  The  display  devices  are  cathode-ray- 
tube  (CRT)  displays  which  are  driven  by  the  MPDG  and  DSMU  as  described 
above.  This  allows  changes  or  additions  to  the  Information  displayed 
to  the  pilot  without  physical  changes  to  or  movement  of  the  display 
devices  In  the  cockpit.  The  CRT  display  devices  consist  of  raster 
written  and  stroke  written  devices  as  follows: 

e Head-Up  Display  (HUD)  - stroke  written 

a riultiple  Purpose  Displays  (HPDs)  - raster  written 

The  MPDs  can  be  used  for  Vertical  Situation  Display  (VSD), 

Horizontal  Situation  Display  (HSD)  and  Multi-Purpose  Displays  (MPDs) 
as  required  by  the  specific  avionics  systems  configuration.  All  the 
Fff’Ds  are  Identical  except  for  the  legends  on  the  display  selection 
buttons.  The  Head-Up  Display  (HUD)  presents  the  symbology  (e.g. 
cues,  flight  Information)  In  the  pilot's  forward  f lei d-of- view,  so 
out-the-window  scenes  (e.g.  targets,  IPs  etc.)  can  be  viewed. 

e.  Data  Entry  Devices.  The  data  entry  devices  provide 
flexibility  In  the  Information  which  can  be  entered  by  the  pilot  to 
control  and  manage  the  specific  avionics  system  (mission  functions, 
sensors,  and  subsystems).  The  design  of  the  data  entry  devices  allows 
changes  or  modifications  to  the  avionics  functions  without  physical 
changes  to  the  cockpit.  The  output  of  the  data  entry  device  Is 
received  and  Interpreted  by  mission  software  via  the  multiplex  system. 

Display  responses  to  the  device  are  generated  by  mission  software  via 
the  multiplex  system.  The  type  of  data  entry  devices  Include  the 
following: 

i 
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1.  Integrated  Multifunction  Keyboard  (IMFK).  The  IMFK 
consists  of  a programnable  alphanumeric  Z90  character  display*  with 
seven  master  function  pushbuttons,  and  ten  submode  select  pushbutton 
switches,  five  on  either  side  of  the  display.  The  IMFK  display  is 
capable  of  displaying  ten  rows  of  characters  divided  into  three  col- 
umns (nine  characters  in  left  and  right  columns,  and  ten  characters 
in  center  column).  The  display  information  is  generated  by  mission 
software.  The  pushbuttons  generate  a request  via  the  remote  terminal 
for  the  master  executive  to  asynchronously  service  and  transmit  the 
data  to  the  appropriate  processor.  Application  software  interprets 
the  pushbutton  or  switch  action  and  provides  the  appropriate  response. 

2.  Multifunction  Keyboard  (MFK).  The  MFK  consists  of 
seven  master  function  pushbuttons,  ten  submode  pushbutton  switches, 
each  with  a rear  projection  display  capability,  and  ten  indicator 
lights.  The  MFK  interfaces  with  mission  software  via  the  RT  like 
the  IMFK,  and  can  be  utilized  for  specific  control  and  display 
functions  or  as  a backup  for  the  IMFK  as  required  for  the  specific 
mission  applications. 

3.  Data  Entry  Keyboard  (DEK).  The  DEK  provides  the  pilot 
with  a means  of  entering  numeric  and  limited  alpha  data  into  mission 
software  via  the  multiplex  data  bus.  The  DEK  stores  and  displays  up 
to  ten  characters.  When  the  enter  key  is  depressed,  a request  for 
services  via  the  RT  is  made  to  the  master  executive.  Upon  receiving 
the  data,  mission  software  application  software  interprets  the  data 
depending  upon  the  selected  submode  via  the  IMFK  or  MFK. 

f.  Control  Devices.  The  Control  and  Display  subsystem 
also  provides  several  control  devices  to  manage  processor  and  multi- 
plex power,  and  system  control  as  follows: 

1.  Processor  Control  Panel  (PCP).  The  PCP  provides 
switches  for  signaling  control  of  power  to  the  multiplex  system  (RT 
sides  A & B)  and  to  each  processor/BCIU.  Application  of  power  to 
each  processor/BCIU  initiates  the  startup  sequence.  The  PCP  also 
includes  momentary  switches  to  enable  the  startup  (cold  start)  and 
restart  (warm  start)  of  the  system. 

2.  Sensor  Control  Unit  (SCU).  The  SCU  provides  for  selec- 

\ tion  and  position  control  of  a symbol  or  sensor  (X  and  Y directions) 

vis  mission  software.  The  hand  controller  is  a force  control  with  DC 
voltage  output  which  is  proportional  to  the  force  in  the  X and  Y 
directions.  The  SCU  also  provides  trigger  and  switch  discrete  outputs. 
These  outputs  are  transmitted  to  mission  software  via  the  multiplex 
data  bus;  and  mission  software  drives  the  appropriate  symbol  or 
sensor  based  upon  the  selected  mode.  The  SCU  also  provides  a control 
knob  to  control  cursor  brightness. 
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3.  Armament  Panel  (AP).  The  armament  panel  provides 
switches  for  weapon  armament  control  (bombing,  fusing,  gun  firing, 
and  jettison). 

4.  Master  Mode  Panel  (MMP).  The  MMP  consists  of  fifteen 
master  mode  switches,  each  with  an  Indicator  light  and  HUD  related 
switches  & controls.  When  a master  mode  switch  Is  depressed,  a 
request  for  service  via  the  RT  will  be  made  to  the  master  executive. 

Upon  receiving  the  data,  mission  software  Interprets  and  responds  to 
the  selected  master  mode. 

The  Interface  between  the  pilot  and  the  Integrated  set  of 
controls  and  displays  Is  dependent  upon  the  specific  avionic  mission 
and  system  configuration.  The  system  designer  would  select  the  set 
of  Integrated  controls  and  displays  required  for  the  specific  avionic 
system,  and  define  the  pilot  sequences  and  display  responses  required 
to  control  and  mode  the  avionics  system. 

The  Interface  between  the  mission  software  and  the  C&D 
application  software  In  the  MPD6  is  also  mission  and  application  depen- 
dent. This  Interface  Is  defined  by  the  data  bus  messages  from  mission 
software  to  the  MPD6  to  perform  the  following  functions: 

• Load  the  MPDG 

• Control  display  (VSD,  MPD,  HAD,  & HUD) 
assignment 

• Control  display  modes 

• Data  to  drive  the  display  symbology,  e.g. 
elevation,  altitude,  heading,  etc. 

• Text  data 

With  Increased  avionic  and  mission  complexity,  the  role  of 
the  pilot  Is  changing  to  that  of  a total  system  manager.  Through  the 
mission  software,  a systems  management  function  can  be  performed  to 
collect  Information  and  control  a functionally  Integrated  set  of  sub- 
systems and  sensors,  thus  reducing  the  pilot  workload.  Functions  such 
as  sii>system  checkout  and  monitoring,  data  computation  and  reduction, 
routine  sequencing  within  mission  modes,  mission  and  aircraft  data 
storage  can  be  performed  by  the  mission  software  during  normal  operat- 
ing ffl^s  or  master  modes  with  minimum  pilot  Intervention.  Operation  by 
exception  can  be  the  design  Into  the  system  control  and  operation. 

For  example,  the  pilot  can  use  the  Integrated  cmtrols  and 
displays  to  mode  the  avionics  system  through  the  mission  software  appll- 
catW  functions.  He  receives  displayed  Information  from  the  software 
about  the  mission  and  avionics  system  operations.  ^The  control  devices 
permit  the  pilot  to  establish  the  operations  to  be  performed  by  the 
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software  functions.  The  master  modes  set  the  display  devices  to  pres- 
cribed formats  via  mission  software  and  the  MPD6.  The  pilot,  however, 
can  override  these  normal  operations  to  either  cause  alternate  modes  or 
activate  operations  not  required  by  the  selected  master  mode. 

Master  modes  can  be  defined  for  specific  phases  of  the  mission 
where  certain  normal  operations  are  active.  Upon  entering  a new  master 
mode,  some  previous  operations  can  be  terminated  as  new  ones  are  activa- 
ted. Manual  modes  previously  selected  by  the  pilot  can  be  retained  if 
compatible  with  the  new  master  mode.  If  the  new  master  mode  requires  a 
system  that  has  been  deselected  using  the  manual  mode,  the  pilot  can  be 
alerted  through  displayed  exception  messages.  The  master  mode  panel,  as 
labeled  for  the  specific  mission  applications,  permits  the  pilot  to 
select  these  prescribed  master  modes.  Mission  software,  in  response  to 
the  selected  master  mode,  will  command  the  C/D  application  software  to 
generate  prescribed  formats  for  the  various  displays  (HUD,  VSD,  MPD, 
etc.).  The  pilot  can  override  the  preprogrammed  mission  functions  through 
the  IMFK  displayed  pages  and  side  keys  which  are  also  handled  by  mission 
software.  The  pilot  will  also  be  able  to  enter  information  into  mission 
software  via  the  DEK.  For  the  DAIS  Demonstration,  a representative  set 
of  master  modes  and  mission  operational  sequences  were  defined  and  imple- 
mented under  control  of  mission  software  application  software  and  C&D 
application  software.  The  requirements  for  these  modes  were  defined  in 
a Pilot/Operational  Sequence  Interface  Control  Document  (ICD). 


3.2.4  DAIS  Mission  Software 

The  mission  software  resides  in  the  DAIS  processor(s)  and  is 
separated  into  the  executive  software  and  the  application  software. 

The  mission  software  consists  of  the  Operational  Flight  Program  (OFP) 
and  the  Operational  Test  Program  (OTP).  The  OFP  application  software 
performs  the  specific  avionic  mission  functions,  while  the  OTP  appli- 
cation software  is  used  on  the  ground,  on  board  the  aircraft,  to 
test  and  isolate  failures  to  the  LRU  level. 

3.2.4. 1 Executive 

The  Executive  is  organized  into  the  local  executive  and 
master  executive. 

a.  Local  Executive.  Each  DAIS  processor  contains  its  own 
local  executive!  The  local  executive  software  is  table  driven  and 
performs  the  following  minimum  functions: 

1.  Process  Control  - provides  services  for  the 
application  software  to  activate  and  deac- 
tivate periodic  and  non-periodic  tasks  when 
appropriate  conditions  have  been  met.  These 
conditions  are  based  upon  logical  settings  > 

(on  or  off)  of  real  time  events. 
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2.  Event  Control  - provides  the  mechanism  for 
setting,  resetting,  and  evaluating  real  time 
events  which  communicate  conditions  (on  or 
off)  signaled  between  tasks  whether  In  the 
same  or  different  processors. 

3.  Data  Control  - guarantee  Integrity  of  shared 
data  and  provide  mechanism  for  transmission 
and  reception  of  data  over  the  multiplex  bus. 

4.  Processor  Initialization  - provides  Initial- 
ization for  processor  power  transient  recovery. 
Initializes  program  loads,  and  minor  cycle 
synchronization  with  the  other  processors. 

b.  Master  Executive.  The  master  executive  software  Is 
also  table  driven  and  manages  the  system  configuration  by  performing 
the  following  minimum  functions: 

1.  System  Synchronization  Control  - allocates 
time  segments  (minor  cycle  and  major  cycle) 
for  synchronous  messages  and  performs  minor 
cycle  synchronization  by  transmitting  minor 
cycle  master  function  mode  commands  to  the 
other  processors. 

2.  Bus  Control  - controls  transmission  of 
synchronous  and  asynchronous  messages  over 
the  multiplex  data  bus. 

3.  System  Error/Fallure  Management  - monitors 
and  analyzes  errors  and  failures  based  upon 
both  bus  and  terminal  devices.  Initiates 
message  retry  procedures  to  recover  from 
message  errors. 

4.  Configuration  Management  - detects  and  Iso- 
lates permanent  device  failures,  maintains 
system  configuration  status,  reports  failure 
to  the  application  software,  and  Initiates 
backup  or  recovery  operation  If  required. 

5.  Mass  Memory  Management  - provides  for  re- 
trieving and  storing  Information  from  the 
mass  memory  on  request. 

3. 2. 4.2  Mission  Software  Architecture 

The  structure  Imposed  upon  the  mission  software  Is  general 
enough  to  accommodate  misslon-to-misslon  changes  or  changes  In  the 
complement  of  avionic  sensors.  It  allows  transition  of  the  application 
Independent  executive  software  as  well  as  valid  application  tasks  to 
other  aircraft  configurations  using  the  DAIS  architecture  (system 
modularity).  „ 


The  application  software  Is  organized  In  a hlerarchlal 
control  tree  structure.  All  application  software  consists  of  tasks 
which  can  be  either  controllers  or  calculators.  Each  task  performs  a 
specific  function  based  upon  Its  Inputs,  and  required  for  Its  outputs. 
Control  over  the  tasks  or  modules  conforms  to  this  hlerarchlal  control 
tree  structure.  This  structure  not  only  defines  the  control  struc- 
tures, but  shall  also  facilitate  modular  application  software  for 
maintenance  and  growth.  The  application  software  would  consist  of  the 
tasks  to  control  the  various  mission  dependent  sensors  (e.g..  Inertial 
navigation  system.  Instrument  landing  system,  TACAN,  radar  altimeter, 
air  data,  etc.)  and  subsystems  (e.g.,  stores,  etc.);  and  perform  the 
various  mission  functions  (e.g.,  navigation,  weapon  delivery,  steering 
navigation  update,  acquisitlon/cueing,  target  fix,  stores  management, 
communication,  etc.). 

The  structures  described  above  are  further  divided  Into 
modular  components.  Each  component  of  the  computer  program  Is  a 
closed  program,  I.e. , single  entry  and  single  exit  point.  In  addition, 
each  component  Is  part  of  a hlerarchlal  structure  where  each  component 
Is  controlled  by  a component  of  the  next  higher  level  of  the  hierarchy. 
The  components  are  chosen  that  Isolate  hardware  functions,  to  localize 
the  Impact  of  changes  to  the  equipment,  and  allow  for  mlsslon-to- 
mlsslon  system  changes. 

Structured  programming  techniques  are  used  as  a tool  to  In- 
crease reliability,  understanding,  and  to  eliminate  Intricate  logic 
that  Is  difficult  to  validate  and  verify.  Only  closed  logic  structures 
—logic  structures  which  have  a single  entry  point  and  a single  exit 
point— are  employed  In  the  construction  of  program  components.  To 
further  emphasize  standardization  and  understanding,  the  higher  order 
language  - JOVIAL  073  - Is  used  for  development  of  all  the  mission 
software  except  for  those  portions  of  the  program  where  computer  time 
must  be  minimized  or  a high  degree  of  numerical  accuracy  Is  required 
or  Interface  with  processor  or  bus  controller  hardware. 

3.2.4. 3 Application  Software 

The  application  software  of  the  OFP  Is  structured  to  facili- 
tate maintenance  and  growth.  The  functional  categories  are  specified  • 
In  the  following: 

a.  Master  Sequencer.  The  master  sequencer  Is  at  the  top 
of  the  application  software  hierarchy  and  controls  the  request  proces- 
sor, configurator,  and  subsystem  status  rmnitor.  This  master  sequencer 
Is  only  required  In  the  master  and  monitor  processors. 

b.  Request  Processor.  The  request  processor  responds  to 
pilot's  requests  and  Invokes  the  appropriate  application  functions 
that  generate  Information  for  displays  or  for  controlling  avionic 

{ support  subsystems. 
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c.  Configurator.  The  configurator: 

1.  Defines  the  set  of  application  functions 
to  be  Invoked  by  request  from  the  request 
processor  or  the  subsystem  status  monitor. 

2.  Generates  a new  set  of  available  functions 
upon  significant  changes  in  mission  phasing 
or  equipment  moding.  This  set  of  functions 
Is  based  on  a global  knowledge  of  overall 
system  status. 

d.  Subsystem  Status  Monitor.  The  subsystem  status  monitor 
monitors  subsystem  failures  and  communicates  the  Information  to  the 
configurator. 

e.  Mission  Operations.  The  mission  operations  (OPS): 

1.  Acts  as  a control  authority  for  operations 
either  when  Invoked  by  phase  selection  by 
the  pilot  or  automatically  when  current 
phases  are  terminated  In  an  emergency  or 
abnormal  condition. 

2.  Exists,  as  a minimum,  for  preflight/ 

Inflight  startup,  take-off,  enroute,  combat 
modes,  approach,  landing,  and  postflight 
shutdown  operations. 

f.  Specialist  Functions.  The  specialist  functions  (SPECS) 
provide  functions  required  by  OPS  modules  or  by  the  pilot  (e.g. , navi- 
gation, onboard  test,  weapon  stores,  etc.). 

g.  Equipment  Itodes.  The  equipment  modes  (EQUIP)  provide 
the  Interface  for  each  piece  of  avionics  equipment  (inertial,  communi- 
cation equipment,  etc.). 

h.  Display  Processors.  The  display  processors  (DISP)  provide 
specific  display  messages  to  drive  the  symbols  and  graphical  displays 

on  the  DAIS  controls  and  displays. 


-30- 


3.3 


Other  Elements 


This  optional  subsystem  supports  the  DAIS  capabilities  to 
load/ reload  program  modules  and  mission  dependent  data,  and  to  record 
data  for  post  flight  analysis. 


The  processor/BCIU  In  control  of  the  DAIS  multiplex  data  bus 
manages  the  system  mass  memory  operation.  This  Is  the  control  processor 
during  startup,  the  master  during  normal  operation,  or  the  monitor  during 
backup.  All  error  handling  as  well  as  the  translation  of  file  level 
Information  to  device  level  Information  Is  performed  by  this  processor. 

A fixed  RT  address  Is  required  for  the  system  mass  memory  In 
order  for  It  to  be  accessed  by  the  bootstrap  routine  during  startup. 

Four  subaddresses  are  required  during  normal  operations  to  support  the 
following  basic  functions: 

Address  Select  - to  set  a starting  address  for  the 
mass  memory  and  specify  If  synchronous  or  asynch- 
ronous operations  are  to  be  performed.  Also  to 
set  read  mode  or  set  write  mode. 

Address  Retrieve  - to  obtain  the  current  (I.e.  next 
to  be  accessed)  mass  memory  address  and  settings  of 
the  Read/Write  and  Sync/Async  flags. 

Read  - to  transfer  data  from  the  mass  memory  and  ■ 
advance  the  current  address  by  the  number  of  words 
transferred. 

Write  - to  transfer  data  to  the  mass  memory  and 
advance  the  current  address  by  the  number  of  words 
transferred. 

The  system  mass  memory  Is  word  addressable  and  contains  approx- 
imately a million  16-b1t  words.  It  Is  self-contained  In  that  a -directory 
on  the  system  mass  memory  Identifies  the  location  of  all  files  stored  In 
the  memory.  A basic  loader  for  the  processor  Is  stored  at  a fixed  loca- 
tion on  the  system  mass  memory,  and  therefore,  available  to  be  read  by 
the  startup  bootstrap  In  the  processor. 

The  system  mass  memory  Includes  a buffered  Interface  to  minimize 
access  delays.  When  an  access  delay  Is  encountered,  this  Is  Indicated  by 
a "not  ready”  bit  In  the  status  word  returned  on  the  bus. 


3.4 


Non-Real  Time  Support  Software 


The  DAIS  non-real  time  support  software  provides  the  tools 
to  develop,  generate,  test  and  partition  the  mission  software  for  the 
specific  avionics  configuration. 

3.4.1  JOVIAL  J73/I  Compiler 

The  JOVIAL  compiler  Is  a non-real  time  program  which  trans- 
lates high-order-language  statements  (J73/I  source  code)  Into  software 
object  modules  (mission  software  and  support  software)  which  can  be 
loaded  and  executed  on  specified  target  computers  (e.g.  DAIS  processors. 
DEC-10  computer).  The  JOVIAL  language  Is  machine  Independent,  using 
self-explanatory  English  words  and  familiar  notation  for  algebraic 
numerical  computations  and  logical  operations.  The  JOVIAL  compiler 
provides  a common,  powerful,  and  easily  understandable  programming 
language,  for  a wide  range  of  applications.  The  comoller  provides 
capability  for  designating  and  manipulating  (sharing)  data  between  Inter- 
dependent programs  or  tasks  through  a communication  pool  (compool). 

The  J73/I  compiler  Is  designed  to  be  easily  retargeted  to 
produce  object  code  for  a new  and  unspecified  computer.  The  J73/I 
compiler  Is  also  designed  to  be  easily  rehostable  to  another  host 
computer.  Initially,  the  J73/I  compiler  was  hosted  on  the  DEC-10 
computer  system,  and  targeted  for  the  DAIS  processor  and  DEC-10  system. 

The  structure  of  the  J73/I  compiler  Is  shown  In  Figure  9. 

The  system  programmer  will  generate  the  J73/I  source  Input  and  compool 
Input  files  using  the  JOVIAL  J73/I  User's  Guide.  The  programmer  will 
then  compile  the  source  program  using  the  J73/I  compiler  which  shall 
produce  source  listings,  cross  references,  object  listings,  and  the 
relocatable  object  files  for  the  selected  target  computer. 

The  output  of  the  J73/I  compilation  Is  relocatable  module 
file.  In  order  to  execute  the  program  on  the  DEC-10.  It  must  be 
converted  from  relocatable  file  to  core  Image  form  using  the  DEC-10 
(LINK-10)  linker  loader.  In  order  to  execute  the  program  on  the  DAIS 
processor.  It  must  also  be  converted  to  core  Image  form  using  the  HBC 
linker  loader. 

The  J73/I  User's  Guide  provides  definition  of  the  J73/I 
language,  properties,  and  statements  Including  examples  of  how  to 
write  a J73/I  program.  The  guide  also  presents  a syntactic  description 
of  the  language  elements  with  examples  and  necessary  Information  for 
user  to  write,  compile,  load  and  execute  programs  on  the  target  com- 
puters. 


SDVS  is  an  Integrated  collection  of  non-real  time  software 
tools  to  aid  in  the  development,  coding  and  testing  of  the  mission 
software  for  the  DAIS  processors.  Through  SDVS,  an  applications  | 

programner  has  such  capabilities  as:  the  automatic  control  of  i 

software  versions  and  changes:  an  all-digital  simulation  capability 
for  executing  and  testing  the  DAIS  mission  software  without  use  of 
the  actual  hardware:  the  automatic  control  of  simulation  runs:  and 
t^  editing  and  analysis  of  the  test-data  generated. 

SDVS  is  basically  composed  of  three  subsystems:  file 
generation  and  data  base  management  subsystem,  a simulation  sub- 
system, and  a post  run  edit  subsystem.  Figure  10  is  a system  over- 
view of  SDVS  stressing  the  subsystem  organization.  ' 

The  following  paragraphs  summarize  the  basic  functions 
or  modes  of  operation  that  SDVS  provides  to  the  users:  ; 

a.  File  Generation.  The  file  generation  mode  pro-  i 

vides  the  necessary  tools  and  configuration  management  aids  for 
maintenance  of  all  files  associated  with  the  development,  test,  and 
verification  of  the  DAIS  software.  An  extensive  cataloging  system  j 

is  maintained  for  a number  of  different  types  of  software.  Including 
DAIS  mission  software,  SDVS  test  case  files  (defining  simulation 
scenarios  and  data  collection  requirements),  environment  and  air-  ■ 

craft  models,  post  run  edit  directive  files  (defining  data  reduction  | 

and  analysis  requirements),  and  post  simulation  data  reduction  and  i 

analysis  programs.  The  user  has  available  a number  of  commands  to  I 

manipulate  SDVS  files  such  as  edit,  copy,  translate,  etc.  j 


The  SDVS  catalogs  provide  configuration  control 
for  the  development,  test,  and  maintenance  of  the  DAIS  mission 
software.  The  user  has  the  capability  to  create  and  edit  JOVIAL 
code  and  COMPOOL  data  files  and  to  create  and  edit  DAIS  assembler 
code.  SDVS  automatically  links  COMPOOL  data  files  to  program  files 
; in  the  catalogs. 

t 

The  user  is  able  to  produce  listings,  save  newly 
created  and  updated  files,  and  invoke  the  JOVIAL  J73  compiler  or  the 
DAIS  assembler.  The  SDVS  automatically  catalogs  all  revisions  made 
to  a mission  software  file,  and  catalogs  object  modules  from  successful 
compilations. 
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FIGURE  10.  SDVS  SYSTEM  OVERVIEW 


b.  Set  Up  and  Run  Simulation.  This  mode  of  operation  Is 
used  to  submit  a simulation  run  based  on  a test  case  directives  file 
that  has  previously  been  created  and  translated.  The  user  Inputs  for 
this  mode  of  operation  Include: 

a Specification  of  the  test  case  file 

a Maximum  simulation  time 

a Time  of  day  for  executing  the  simulation 

SDVS  automatically: 

a Retrieves  the  test  case  file  and  loads  ^ 

the  specified  mission  software  for 
simul atlon 

a Interacts  with  the  machine  operator  to 
mount  the  necessary  tapes 

a Performs  Initialization  commands 
specified  in  the  user's  test  case 

a Executes  the  desired  simulation  scenario 

a If  specified  in-  the  test  case,  automatically 
transfer  control  to  the  Post  Run  Edit  mode 
and  perform  post  run  data  analysis  and 
editing  on  the  simulation  data 


The  SDVS  code  executors  consist  of  both  a Statement  Level 
Simulator  (SLS)  and  an  Interpretive  Computer  Simulator  (ICS).  The  SLS 
executes  mission  software  generated  by  the  J73  compiler  for  execution 
on  the  host  DEC-10,  while  the  ICS  executes  the  actual  DAIS  processor 
code  with  bit  level  accuracy.  Since  the  SLS  actually  executes  on  the 
DEC-10,  the  throughput  Is  very  highly  compared  to  the  Interpretive 
execution  of  the  ICS.  These  two  tools  provide  the  user  a choice  of 
fidelity  In  the  simulation  of  mission  software  code. 

c.  Post  Run  Edit.  The  post  run  edit  mode  provides  the  user 
with  the  ability  to  analyze  the  data  recorded  on  a rough  output  tape 
during  a simulation  run.  The  post  run  editor  Is  driven  by  the  user- 
specified  post  run  edit  directives  file.  The  directives  specify  what 
data  Is  to  be  selected  from  the  rough  output  tape,  what  analysis  Is  to 
be  run  on  that  data,  what  format  1s  to  be  used  to  display  the  analysis 
results,  what  user  routines  are  to  be  used,  and  what  devices  are  to 
receive  the  output  files  created  by  the  post  run  editor. 


r 


I 


The  post  run  editor  provides  tabular  printouts  and  data 
plots  based  on  user  directives.  An  Important  feature  Is  the 
ability  for  a user  to  write  an  analysis  routine  In  JOVIAL  and  have 
It  execute  within  the  fr^atnework  of  the  post  run  editor.  The  post 
run  editor  mode  performs  In  batch  or  on  line  with  results  displayed 
on  the  users  terminal. 

d.  Rollback.  The  user  may  specify  that  all  data  necessary 
to  restart  a simulation,  from  a particular  point  In  the  simulation,  be 
saved  on  a snapshot  tape.  The  rollback  function  Is  using  the  snapshot 
tape  to  provide  simulation  restart  capability.  The  user  may  use  the 
original  test  case  or  he  may  modify  the  original  directives  to  obtain 
additional  output  or  to  alter  existing  simulation  conditions. 

The  output  of  this  mode  of  operation  Is  a simulation 
run  which  (If  no  changes  were  made  In  the  test  case  directives)  will 
exactly  match  the  previous  one.  Changes  may  be  made  to  provide 
further  analysis  of  a simulation  run  which  Is  of  special  Interest. 

<1*  Delete  Mode.  This  mode  of  operation  shall  be  only 
available  to  the  SbV^  manager  and  provides  him  the  capability  to 
delete  files  from  the  various  SDVS  catalogs.  This  function  shall  be 
made  a manager  level  function  to  allow  manager  level  control  over  the 
disposition  of  all  files. 

f.  Supervisor  Mode.  This  mode,  like  the  delete  mode, 
shall  be  available  only  to  the  SDVS  manager  for  configuration  control 
purposes.  One  of  the  features  of  the  SDVS  file  management  scheme  Is 
that  before  a user  may  generate  any  file  In  the  file  generation  mode, 
specifications  must  have  been  created  for  that  file.  Including  the 
provision  of  a list  of  users  who  are  authorized  to  write  on  the  file, 
and  If  appropriate,  a list  of  users  who  are  free  only  to  read  It. 

The  creation  of  file  specifications  are  performed  from  supervisor  mode. 
This  mode  Is  entered  only  by  a SDVS  user  logged  In  on  the  special 
number. 
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3.4.3  Partitioning  Analyzing  and  Linkage  Editing  Facility  (PALEFAC) 


PALEFAC  Is  a non-real  time  support  software  tool  for  use  by 
the  system  designer  and  application  programmer  to: 

1.  Build  the  data  tables  for  the  DAIS  local 
and  master  executives. 

2.  Provide  bus  analysis  and  module  partitioning 
information. 

3.  Produces  the  executive  tables  in  J73/I 
source  code. 

4.  Generate  linker  comnand  files  for  each  DAIS 
processor  for  the  DEC-10  Linker  or  DAIS 
Processor  Linker. 

PALEFAC  may  be  used  as  a standalone  tool , or  under  control  of 
SDVS.  PALEFAC  consists  of  three  basic  programs,  as  shown  In  Figure  11; 
PALEFAC  pre-processor,  PALEFAC  main  program,  and  PALEFAC  module  input 
(PMI)  decoder. 

PALEFAC  is  used  to  build  the  mission  software  load  modules 
for  each  of  the  DAIS  processors.  Inputs  to  PALEFAC  are  the  application 
software  modules  Including  the  executive  service  requests  generated  by 
the  application  programmer  in  J73/I  source  code.  The  pre-processor 
reads  each  application  module  and  creates  a record  for  each  application 
module  In  the  PMI  file. 

The  system  designer  will  prepare  PALEFAC  Global  Input  (PGI) 
file  based  upon  the  specific  system  configuration,  partitioning  of 
application  tasks  to  each  processor,  and  bus  messages  to  each  terminal. 
This  would  Include: 

a.  Bus  Messages 

• To/from  data  block  name  or  Terminal  Address/ 
Subaddress 

e Cycle  (period  and  phase)  for  synchronous 
transmissions 

e Activity  request  Identification  for  asynch- 
ronout  transmission 

• Vlord  count 

e Class  for  message  error  retry 
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FIGURE  n.  PALEFAC  OVERVIEW 


b.  List  of  all  tasks  or  modules  for  each  processor 

c.  Override  directives 

d.  Number  of  processors  in  the  system  configuration 
and  address  of  each  terminal 

The  system  designer  mill  also  generate  the  PALEFAC  Auxiliary  File  (PAL) 
for  common  subroutines  (comsubs)  and  coninon  communication  data  blocks 
(compools). 

The  PALEFAC  main  program  builds  the  executive  tables  and 
linker  command  files  based  upon  the  system  designer  specified  config- 
uration. The  output  of  PALEFAC  is  the  PALEFAC  mission  files  (PMD), 
PALEFAC  Partitioning  Information  Files  (PPI),  and  test  output  files 
shown  in  Figure  11.  The  PMD  files  contain  all  the  executive  tables 
including  the  bus  control  tables  in  J73/I  source  code.  The  PPI  files 
contain  the  linker  commands  for  each  processor  and  specify  all  the 
mission  software  modules  (e.g.  executive  modules,  application  tasks, 
comsubs,  and  executive  tables)  in  order  for  the  linker  to  produce  the 
load  modules  for  each  processor.  PALEFAC  also  produces  text  output 
files  listing  all  the  PALEFAC  input  files,  the  output  files,  and  error 
messages. 
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4.0 


DAIS  SYSTEM  CHARACTERISTICS  AND  FEATURES 


The  performance  characteristics  of  DAIS  Include  both  system 
functional  control  characteristics  as  well  as  system  architecture 
features  and  attributes  Included  In  the  design  of  DAIS  and  Its  core 
elements.  These  sections  address  the  system  control  features  and  the 
primary  characteristics  which  are  unique  and  Important  to  the  DAIS 
concept.  ' ” 


• 1 • 
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4.1  System  Control  Procedures 

This  section  describes  the  system  control  procedures  for 
DAIS.  The  DAIS  architecture  and  integrated  system  design  results  in 
a special  set  of  functional  requirements,  designated  system  control 
procedures,  which  Include  system  startup/restart,  control  of  the  bus 
comnuni cation  and  utilization  of  redundancy  in  the  event  of  core 
element  failures.  The  system  and  bus  control  functions  are  distin- 
guished from  mission  avionic  functions  which  support  the  specific 
mission  tasks.  The  mission  avionic  functions  could  be  comprised  of 
navigation,  guidance,  weapon  delivery,  comnuni cations,  vehicle  defense, 
target  acquisition  and  track,  auto  pilot,  stores  management,  and 
subsystem  management. 

A third  important  group,  on-board  test  functions,  utilize 
both  hardware  and  software  to  isolate  in-flight  failures  to  allow 
utilization  of  redundancy,  maintain  a complete  updated  status  of 
every  equipment  on  the  system,  and  provide  isolation  of  failure  to 
LRU  levels  with  a minimum  of  auxiliary  group  equipment. 

4.1.1  System  Startup/Restart  Operations 

The  overall  objective  of  the  system  startup/restart  pro- 
cedures is  to  give  the  pilot  control  of  the  system  configuration  and 
to  provide  a verification  of  the  hardware  and  software  prior  to 
entering  normal  system  operations. 

The  pilot  controls  the  system  via  the  Processor  Control 
Panel  (PCP).  The  power  enable  switches  allow  him  to  remove  a proces- 
sor from  the  system  by  powering  it  down.  The  GROUND  position  of  the 
startup  switch  permits  him  to  specify  an  initial  startup  as  opposed 
to  a restart,  indicated  by  the  INFLIGHT  position.  The  START  button 
permits  him  to  request  the  use  of  software  already  loaded,  while  the 
LOW)  button  allows  him  to  force  the  reload  of  all  software.  Of 
course,  the  LOAD  function  is  supported  only  when  a system  mass  memory 
is  configured  in  the  system. 

In  addition  to  the  pilot  initiated  restarts,  the  system 
will,  under  certain  limited  circumstances,  perform  an  automatic 
restart.  It  is  essential  that  an  automatic  restart  have  minimal 
impact  to  continue  system  operation.  This  consideration  defines 
the  need  for  a "warm  start"  initialization  of  software  as  opposed 
to  the  "cold  start"  associated  with  normal  system  startup. 

"Cold  start"  assumes  a fully  operational  configuration. 

It  Involves  the  conplete  initialization  of  executive  and  application 
software,  and  the  assignment  of  initial  values  to  events  and  data. 

"Warm  start"  continues  the  current  operational  status.  A 
partial  initialization  of  the  executive  is  performed,  current  data 
is  maintained,  and  application  tasks  and  events  are  assigned  to  a 
known,  predetermined  state. 
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The  various  startup/ res tart  cases  are  summarized  In 

Table  3. 

As  is  evident  from  this  table,  it  is  important  the  pilot 
set  the  startup  switch  before  powering  up  the  processors.  Otherwise, 
the  power  up  would  look  like  a transient  recovery.  Conversely,  the 
pilot  must  return  the  switch  to  the  INFLIGHT  position  at  the  comple- 
tion of  a normal  startup.  Failure  to  do  so  would  allow  a transient 
to  bring  the  system  to  a stop. 

4. 1 . 1 . 1 Normal  System  Startup 

Each  processor  is  equipped  with  a read  only  memory  (ROM)*, 
which  is  enabled  when  the  power  up  condition  is  detected.  The  ROM 
contains  sufficient  instructions  for  the  processors  to  identify  the 
configuration,  verify  the  software  load  modules  and,  if  necessary, 
obtain  the  system  loader  from  the  system  mass  memory.  The  ROM  may 
contain  additional  functions  as  desired  for  any  specific  implementa- 
tion, but  normally,  considerations  of  stability  and  size  would  indi- 
cate only  essentials  should  be  in  the  ROM.  The  minimum  ROM  contents 
are  dictated  by  the  requirement  that  the  ROM  be  capable  of  starting  " 
or  restarting  a system  without  a system  mass  memory. 

'As  each  processor  senses  power  up,  it  enables  the  ROM  and 
begins  executing  at  location  zero.  Memory  protection  is  established. 
Interrupts  are  cleared,  and  self  tests  are  performed  on  the  processor 
and  BCI. 

At  the  completion  of  self  tests,  the  second  phase  of  the 
startup  process  is  initiated.  This  is  a coordinated  procedure  for 
I establishing  one  processor  as  the  controller  of  the  startup  and  for 

iden-tifying  the  configuration  to  be  run.  A processor  is  included  in 
the  configuration  if  it  passed  self  test  and  it  successfully  co— uni- 
cates  on  the  multiplex  bus  in  response  to  coMsands  from  the  controller. 
Also,  during  this  phase  of  startup  each  processor  detefmines  the 
status  of  the  software  load  in  it's  neMory. 

The  third  phase  of  the  startup  process,  software  verifica- 
t tion/loading,  is  then  entered.  Based  on  the  configuration  which  Is 

operational,  the  controller  accesses  a startup  configuration  table  to 
I determine  the  load  nodule  required  in  each  processor.  If  the  required 


The  ROM,  in  effect,  overlays  the  first  two  thousand  words  of  nenory 
while  envoked.  This  is  a feature  of  the  AN/AYK-15A  processor  and, 
since  it  is  the  preferred  lBt>1eHentat1on,  the  startup  procedures  are 
described  in  this  context.  With  the  AN/AYK-15,  or  other  processor 
not  equipped  with  a ROM,  the  startup  software  must  be  permanently 
preserved  in  low  nenory  and  nenory  protected  except  as  required  when 
nodifying  Interrupt  vectors. 


TABLE  3.  START/RESTART  CASES/OPTIONS 


WARM  START 


software  Is  not  present,  It  Is  loaded  from  mass  memory • and  the  verlf-' 
icatlon  process  repeated.  When  It  Is  confirmed  that  all  processors 
are  properly  loaded,  BCIU  addresses  are  reset  to  the  logical  ones 
required  In  the  configuration.  The  Master  processor  assumes  control 
and  directs  the  set  up  for,  and  execution  of,  system  Initialization 
prior  to  starting  system  operation. 

4. 1.1. 2 System  Warm  Start 

System  Warm  Start  Is  designed  primarily  as  a response  to 
a system  wide  power  transient.  The  objective  of  a warm  start  Is  to 
get  back  on  the  air  as  quickly  as  possible.  The  procedure  warm  starts 
what  It  finds  and  verifies  In  the  processors’  memory  and  does  not 
perform  reloading. 

As  power  Is  restored  to  each  processor.  It  will  enter  the 
ROM,  perform  self  tests,  verify  software  and  build  a startup  status 
block  as  In  normal  startup.  The  absence  of  any  bus  activity  permits 
one  of  the  processors  to  assume  the  role  of  control  processor  to  manage 
the  warm  start.  The  fact  that  It  Is  a warm  start  Is  determined  by 
^e  INFLIGHT  position  of  the  start  switch  and  the  absence  of  both  the 
discretes  for  the  start  button  and  the  load  button. 

The  startup  configuration  table  defines  the  acceptable 
configurations  for  a warm  start  In  their  order  of  preference.  If  the 
procedure  cannot  find  the  configuration  matching  the  Initial  load  word 
(which  by  definition  Is  the  most  preferred  configuration  for  a warm 
start)  It  then  goes  through  the  alternate  list  trying  to  find  a con- 
figuration In  which  all  the  load  module  ID's  can  be  found  In  some 
processor. 

The  system  Implementer  defines  the  preference  order  for  a 
warm  start  by  the  order  of  the  entries  In  the  startup  configuration 
table.  One  option,  of  course.  Is  to  make  no  entries  of  alternates, 
which  has  the  effect  of  Inhibiting  warm  starts  for  anything  other  than 
the  Initial  load  configuration.  Care  should  be  exercised  to  Insure 
the  recovery  mode  of  a larger  configuration  Is  always  Included  In  the 
alternate  list.  Otherwise  a transient  would  terminate  a recovery 
mode  of  operation. 

4.1.2  Normal  System  Operation 

Normal  system  operation  functions  define  the  management  of 
the  processor/fflultiplex  system  configuration  (Figure  2).  One  of  the 
processors,  designated  the  master  processor,  contains  the  master  exec- 
utive and  controls  the  bus  protocol  via  the  BCIU  operating  with  It. 

The  application  software  Is  distributed  among  the  remainder  of  the 
processors  with  each  designated  as  a remote  processor,  and  each  con- 
taining a local  executive.  If  required,  another  processor  can  be 
^slgnated  the  monitor  processor  and  would  contain  the  backup  master 
executive  and  application  modules. 
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4.1. 2.1  Bus  Control  Operation 


The  time  division  multiplexing  (TDM)  system  provides  for 
transmission  of  Information  from  several  terminals  through  a single  , 
comnunl cation  system,  with  different  terminals'  Information  trans- 
mission staggered  In  time  In  accordance  with  MIL-STD-1553A. 

The  message  structure,  data  format  and  command- response 
protocol  required  for  the  bus  operation  are  defined  In  MIL-STD-1553A 
and  are  summarized  In  Figure  4.  One  exception  was  made  to  the  pro- 
tocol In  the  standard  In  order  to  facilitate  error  management  and 
control.  This  pertains  to  terminal  (or  remote  BCIU)  response  to 
receive  data  errors,  and  response  to  receive  or  transmit  commands 
containing  errors.  For  any  detected  data  error,  (I.e.  Incorrect  word 
count,  no  data  received,  parity  error,  or  Improper  Manchester  coding) 
the  terminal  will  not  respond  with  a status  word.  The  terminal  will 
also  Ignore  a command  word  not  received  entirely  valid.  These  opera- 
tions are  required  to  avoid  simultaneous  RT  response  and  to  maintain 
error  control  within  the  master  controller. 

Message  protocol  Is  defined  as  that  sequence  of  bus  messages 
required  to  perform  the  normal  multiplex  synchronous  and  asynchronous 
operations  and  to  support  the  error  detection  and  recovery  process. 

In  order  to  Insure  minimum  processor  executive  and  multiplex  bus 
overhead  required  to  Implement  the  message  protocol,  two  concepts  are 
Introduced:  mode  commands  and  system  control  procedures  (Figure  12). 

System  control  procedures  define  the  message  protocol  for 
the  multiplexed  data  bus  system.  They  serve  to  provide  the  executive 
software  designer  with  the  logical  decisions  required  to  manage  normal 
system  operation.  They  also  define  the  required  system  flow  to  detect 
and  recover  from  random  bus  message  errors  and  selective  terminal 
failure  modes.  The  system  control  procedures  serve  to  link  the  exec- 
utive mission  software,  bus  message  protocol,  and  the  termlnal-to- 
subsystem  Interface  management. 

A time  slice  approach  where  messages  occur  on  a minor  cycle/ 
major  cycle  basis  Is  used  to  control  bus  message  operations.  Messages 
that  are  transmitted  at  specific  Iteration  rates  within  a major  cycle 
are  defined  as  synchronous  messages.  Each  synchronous  message  Is 
assigned  a period  and  phase  for  transmission.  The  number  of  minor 
cycles  per  major  cycle  Is  specified  by  the  system  designer,  for  example 
128  minor  ^cles  every  second  or  major  cycle.  Messages  that  are  to  be 
transmitted  on  a demand  or  request  basis  and  not  at  a specific  phase 
and  period  are  designated  as  asynchronous  messages.  Table  4 
simanarizes  the  bus  control  operations. 
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Bus  control  operations  provide  for  major/mlnor  cycle  synch- 
ronization by  transmission  of  minor  cycle  sync  mode  comnand  messages 
to  each  remote  BCIU/processor,  and  for  synchronous  and  asynchronous 
bus  message  transmissions  as  shown  in  Figure  13.  The  synchronous  bus 
messages  are  controlled  by  a predefined  bus  Instruction  list.  The 
bus  Instruction  list  Is  part  of  the  Master  Executive  preloaded  tables 
and  contains  an  instruction  pair  for  each  synchronous  message  that  Is 
transmitted  on  the  data  bus.  Since  each  message  Is  not  transmitted 
every  minor  cycle,  the  Instruction  lists  are  organized  so  that  the 
proper  instruction  pairs  can  be  linked  together  at  the  start  of  each 
minor  cycle  to  form  the  complete  Instruction  list  for  that  minor 
cycles'  period  and  phase.  The  link  Instruction  pairs  are  dynamically 
set  by  the  master  executive  to  point  to  the  proper  block  of  Instruc- 
tions to  be  performed  during  the  current  minor  cycle. 

Each  data  word  on  the  bus  is  transferred  from  the  bus  con- 
troller (whether  master  or  remote)  to  the  processor's  memory  In  real 
time  via  a direct  memory  access  channel.  The  address  at  which  each 
message  block  begins  Is  constructed  by  fetching  first  the  receive  (or 
transmit)  pointer  word  and  by  combining  the  current  base  address, 
the  transmit/receive  bit,  and  the  subaddress  Into  the  pointer  address. 
Consecutive  data  words  are  stored  In  contiguous  memory  locations  until 
the  word  count  for  that  particular  message  Is  exhausted.  For  all 
receive  operations,  each  message  block  Is  preceded  by  a generated  tag 
word  which  contains  the  current  minor  cycle  number,  word  count  of  the 
received  message,  and  any  message  error  relative  to  the  received 
message. 

Asynchronous  messages  are  scheduled  by  the  master  executive 
based  upon  requests  from  remote  terminals,  or  application  tasks  In 
either  the  master  or  remote  processors  or  from  the  master  executive 
to  perform  message  error  or  terminal  failure  operations.  Subaddress  31 
Is  dedicated  to  asynchronous  processor/BCIU  messages.  After  receiving 
or  transmitting  an  asynchronous  message,  the  BCIU  Interrupts  the  pro- 
cessor and  the  local  executive  updates  the  pointer  word  for  storing 
and  fetching  the  data  for  the  asynchronous  message.  The  first  word 
of  all  asynchronous  messages  Is  used  to  designate  the  source  of  the 
message  to  the  receiving  processor.  This  asynchronous  message  Iden- 
tifier Is  used  to  direct  the  local  executive  to  a predefined  table 
containing  Information  to  process  the  data  or  perform  the  executive 
services  action  required. 

There  are  several  types  of  asynchronous  bus  message  opera- 
tions based  upon  the  resource  making  the  request  and  protocol  to  pro- 
cess the  request  as  defined  In  Table  4.  Upon  receiving  the  request, 
the  master  executive  will  cause  the  BCIU  to  halt  after  completing  the 
current  message  transmission,  and  link  In  a predefined  or  generated 
BCIU  Instruction  pair  to  Initiate  the  asynchronous  message  transmission. 


^Refers  to  either  the  processor  & BCIU,  or  Integrated  processor/BCIU. 
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Figure  14  shoMS  the  message  protocol  sequence  for  a subsystem  connected 
to  an  RT  requesting  service.  Asynchronous  operations  would  be  used  for 
pilot  panel  Inputs  and  weapon  release  messages,  as  examples.  Figures  15 
and  16  show  asynchronous  message  protocol  sequences  ror  Interprocessor 
operations.  Interprocessor  messages  would  be  used  to  signal  master 
mode  changes  between  application  tasks  In  different  processors,  and 
steering/guidance  waypoint  passage,  as  examples. 

4.1. 2. 2 Mode  Command  Operations 

In  order  to  support  these  system  control  procedures,  a set 
of  mode  code  operations  are  provided.  The  mode  code  operations  are 
defined  fixed-length  messages  that  Induce  a predetermined  response 
from  a remote  device.  There  are  three  general  classes  of  mode  opera- 
tions: 

a.  Those  that  require  a specific  data  transfer 
from  the  controller  to  a remote  device,  as 

In  a normal  controller- to- terminal  operation. 

b.  Those  that  require  a specific  data  transfer 
from  a remote  device  to  a controller,  as  in 
a normal  terminal -to- controller  operation. 

c.  Those  that  require  a status  response  along 
with  no  data  transfer. 

The  mode  code  operation  is  Indqced  by  an  all  zero  subaddress 
coninand  field;  with  the  mode  code  in  effect  as  determined  In  the  word 
count  field  as  defined  in  MIL-STD-1553A.  Table  5 specifies  the  mode 
convnands  required  to  support  normal  operation  and  error/failure  manage- 
ment. Node  coitmands  1,  3,  and  10  are  used  to  support  detection  and 
recovery  from  bus  message  errors;  mode  commands  3,  4,  5,  6,  7,  9,  and 
22  are  used  to  support  terminal  failure  analysis;  mode  commands  11,  12, 
13,  and  14  are  used  to  support  a Remote  Terminal's  IM  serial/digital 
channel  request,  analysis  and  retry  operation.  Mode  code  17  is  used 
to  synchronize  each  remote  processor  at  the  beginning  of  a minor 
cycle.  Mode  command  3 requests  the  Bullt-In-Test  (BIT)  register  con- 
sisting of  a terminal  failure  field  and  message  error  field,  each 
containing  appropriate  Indicators  that  are  "or'd"  into  the  terminal 
fall  and  message  error  bits  of  the  status  word  respectively.  The 
terminal  fall  field  Is  reset  by  mode  command  22  and  the  message  error 
field  Is  reset  by  the  next  valid  receive  or  transmit  command. 

Node  codes  15  and  16,  respectively.  Induce  bit  and  word  mask 
operations  In  the  RT  for  the  sibsequent  data  bus  message.  The  bit  mask 
and  word  mask  operation  can  be  used  by  the  system  designer  when  parti- 
tioning a data  bus  message  that  requires  data  from  two  sources.  Mode 
codes  20  and  21  are  used  to  perform  failure  analyals  and  recovery  of 
a remote  BCIU/Processor  from  a continuous  busy  condition. 
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FIGURE  14.  ASYNCHRONOUS  MESSAGE  PROTOCOL  - REMOTE  TERMINAL  REQUEST 


TABLE  5.  MODE  CODE  COMMANDS 
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Table  5 Indicates  which  mode  code  operations  are  required  In 
a remote  device  In  order  to  be  compatible  with  the  DAIS  system  control 
procedures  and  master  executive.  Utilization  of  the  other  mode  code  . 
operations  1;  optional  as  determined  by  the  system  designer  for  the^ 
specific  system  application. 

Table  6 shows  the  use  of  the  mode  commands  In  relationship 
to  the  system  control  functions. 

4.1.3  Application  Software  Executive  Services  • 

The  DAIS  Local  Executive  provides  services  for  the  applica- 
tion software  to  control  the  operation  of  the  application  functions 
and  data  In  each  Individual  DAIS  processor.  The  application  software 
elements  which  are  recognized  by  the  local  executive  software  are' 
Tasks,  Comsubs,  Compool  Blocks,  and  Events,  defined  as  follows:  < 

a.  Tasks  are  programs  or  processing  modules  which  can 
either  be  controllers  or  calculators.  Application  software  Is  organ- 
ized In  tasks  (program  modules)  with  each  performing  a function  as 
required  for  the  specific  system  application.  Each  task  contains 
executable  code  and  local  data. 

b.  Corns ubs  are  common  subroutines  which  differ  from  tasks 
In  that  they  are  required  to  be  re-entrant.  Comsubs  can  be  used  by 
many  tasks,  so  that  one  task  using  a particular  comsub  can  be  sus- 
pended In  the  middle  of  the  comsub  routine  by  another  task  using  the 
same  comsub. 

c.  Compool  Blocks  provide  data  communication  between 
tasks  and  the  external  world  or  equipment.  A buffer  system  Is  pro- 
vided by  the  use  of  "global  copies"  and  "local  copies"  to  prevent  a 
compool  block  from  being  read  when  It  has  been  partially  updated. 

Every  task,  except  "privileged"  tasks.  Interface  with  a local  copy 
while  performing  Its  calculations.  The  local  copy  Is  updated  from 
the  global  copy  with  the  read  statement  and  the  local  copy  updates 
the  global  copy  by  the  write  statement.  A special  statement  (trig- 
ger) Is  used  for  a critically  timed  compool  block. 

In  a "privileged"  task,  communication  Is  allowed  directly 
with  the  global  copy  In  the  processor  In  which  the  task  resides  since 
the  privileged  task  cannot  be  Interrupted  by  another  task  or  by  the 
Executive. 

Since  the  read,  write,  and  trigger  statements  Invoke  Exec- 
utive services  that  operate  In  the  Privileged  Mode,  this  guarantees 
a task  will  not  reference  partially  updated  data. 


The  application  software  requests  service  of  the  executive 
through  real  time  statements.  Real  time  statements  are  used  by 
tasks  to  control  the  state  of  other  tasks*  control  values  of  events, 
and  control  reference  to  compool  blocks.  These  are  J73/I  defined 
statements  which  the  application  programmer  will  use  during  the 
development  of  mission  software  as  follows: 

Schedule  Statement 
Cancel  Statement 
Terminate  Statement 
Walt  Statement 
Signal  Statement 
Read  Statement 
Write  Statement 
Trigger  Statement 
Broadcast  Statement 

The  first  four  statements  shall  be  used  to  control  task  states.  At 
any  one  time,  a task  shall  be  In  one  of  these  states  and  the  method 
of  transitioning  from  one  state  to  another  state  Is  shown  In  Figure  17. 

a.  Schedule  Statement.  Schedule  statements  are  used  to 
place  an  uninvoked  task  Into  an  Invoked  state.  An  Invoked  task  becomes 
active  and  dispatchable  when  the  required  event  conditions  are' satis- 
fied as  shown  in  Figure  17.  An  Invoked  task  Is  placed  In  execution 

by  the  Executive  If  It  has  the  highest  priority  among  the  tasks  which 
are  dispatchable. 

A schedule  statement  Includes  the  name  of  the  task  to  be 
scheduled,  the  mode  of  task  (privileged  or  normal),  priority  of  the 
task,  and  event  conditions  to  be  satisfied. 

b.  Cancel  Statement.  The  Cancel  Statement  Is  tised  by  one 
task  to  place  another  task  In  the  Uninvoked  State.  If  a task  Is  can- 
celled, all  the  lower  branches  or  sons  of  the  tasks  In  the  control  tree 
structure  are  cancelled. 

c.  Terminate  Statement.  The  Terminate  Statement  Is  used  by 
one  task  to  place  another  task  In  the  Inactive,  but  Invoked  state.  If 
a task  Is  terminated,  all  the  lower  branches  or  sons  of  the  tasks  In 
the  control  tree  structure  are  also  terminated. 

d.  Walt  Statement.  Walt  Statements  are  used  by  tasks  to 
place  themselves  Into  the  Walt  State  pending  occurrence  of  one  of  the 
following  conditions: 

1.  Absolute  Time 

2.  Relative  Time 

3.  Latched  Event 

4.  Unlatched  Event 

For  the  latched  or  unlatched  events,  the  task  remains  In  the  Walt 
State  until  the  specified  event,  either  on  or  off,  occurs. 
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e.  Signal  Statement.  Signal  Statements  are  used  by  tasks 
to  set  a specified  event  to  a specified  value,  either  on  or  off. 

f.  Read  Statetiy)t.  Read  Statements  are  used  by  tasks  to 
copy  the  values  of  specified  compool  blocks  (global  copies)  Into  a 
local  copy  to  be  used  by  the  task. 

g.  Write  Statement.  Write  Statements  are  used  by  the  tasks 
to  copy  the  values  of  specified  local  copy  Into  the  specified  compool 
block  (global  copy).  The  Write  Statement  causes  global  copies  in 
other  processors  or  virtual  copies  1n  remote  terminals  to  be  updated, 
and  causes  signalling  of  an  event  associated  with  the  compool  block. 

h.  Trigger  Statement.  The  Trigger  Statements  are  used  by  a 
task  to  send  a specified  critically  timed  compool  block  (data)  to  a 
specified  remote  terminal  at  a specified  time.  This  causes  a critic- 
ally timed  asynchronous  bus  message  operation  to  be  performed  where 
the  local  copy  of  a specified  compool  block  Is  sent  to  a. global  copy. 

In  the  Master  Processor;  and  where,  at  the  specified  time,  the  data  Is 
transmitted  asynchronously  to  the  specified  remote  terminal. 

1.  Broadcast  Statement.  The  Broadcast  Statement  ts  used 
only  by  a privileged  mode  task.  After  updating  a global  copy  of  a 
compool  block,  the  broadcast  statement  Is  used  to  cause  the  asynch- 
ronous update  of  remote  and/or  virtual  copies  of  the  compool  block. 

4,1.4  Error  and  Failure  Management. 

Bus  message  error  management  and  terminal  failure  management' 
are  performed  by  the  master  BCIU  and  the  master  executive.  In  addi- 
tion, each  terminal  on  the  multiplex  data  bus  provides  mechanisms' 
for  detecting  and  recording  message  error  conditions  and  terminal 
failures.  M^sage  error  conditions  and  terminal  failure  conditions  . 
are  recorded  In  the  Built-In-Test  (BIT)  word  which  can  be  obtained  r 
by  the  master  with  a mode  command  for  message  error  and  terminal 
failure  analysis.  Also,  each  terminal  records  In  a register  (Last 
Command)  the  last  valid  command  received  by  that  terminal  which  also, 
can  be  obtained  by  the  master  with  a mode  comnand  for  message  error  ' ' 
analysis. 

* . * . 

The  master  executive  and  BCIU  centrally  manages  the  message 
protocol  to  recover  from  message  errors  and  reconfigure  for  terminal  - 
failures  as  follows: 

a.  Monitors  the  message  sequence  to  determine 
successful/unsuccessful  completion. 

b.  Analyze  error  response  (data  error  or  Invalid 

status,  or  no  response  to  command)  and  deter- 
mine type  of  retry  procedure  for  the  unsuc-^^^- 
cessful  message.  . 
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c.  Pftrfom  retry  of  unsuccessful  message,  first 
on  the  same  data  bus  path. 

d.  Analyze  error  response  If  not  successful,  and 
retry  the  unsuccessful  message  on  redundant 
data  bus  path.  If  available. 

e.  Perform  failure  analysis  If  retry  of  message 
on  alternate  bus  Is  unsuccessful  and  deter> 
mine  recovery  or  backup  approach. 

f.  Update  the  system  configuration  tables  based 
upon  the  error  conditions  and  failures. 

Table  7 describes  the  operation  of  the  master  BCIU  to 
various  t/pos  of  bus  message  errors  relative  to  the  three  classes  of 
data  transfer  protocol.  An  Invalid  word  (conmand,  data  or  status) 
would  Include  one  or  more  of  the  following  conditions: 

• Parity  error 

a Incorrect  or  missing  sync 

a Incorrect  bit  count 

a Invalid  manchester  format 

A remote  receiver  will  not  respond  with  a status  word  after 
detecting  a message  error.  Both  remote  receivers  and  transmitters 
Ignore  Invalid  commands.  The  last  comnand  (I.e.  the  last  valid  received 
command)  register  and  the  message  error  field  of  the  Bullt-In-Test 
register  are  stored  as  shown  In  Table  7.  As  message  data  Is  received 
by  a BCIU,  It  Is  stored  In  the  processor  memory  via  DHA.  If  received 
unsuccessfully,  the  message  error  bit  In  the  tag  word  Is  set.  As 
message  data  Is  received  by  an  RT,  the  data  Is  temporarily  stored.  If 
received  successfully,  the  data  Is  transferred  to  the  respective  sub- 
systems; otheixlse.  It  Is  not  transferred  to  the  subsystems. 

All  bus  errors  are  grouped  Into  a set  of  message  error  Indi- 
cations by  the  master  BCIU  as  shown  In  Table  7.  These  error  Indica- 
tions will  generate  an  Interrupt  to  the  master  processor  which 
contains  the  service  routine  required  to  Initiate  a retry  procedure 
shown  In  Table  8.  Depending  upon  the  type  of  bus  message  operation 
and  master  BCIU  message  error  Indication,  the  appropriate  retry  pro- 
cedure as  shown  In  Table  9 would  be  Initiated. 

Error  analysis  and  message  retry  procedures  are  performed 
by  the  Master  Processor/BCIU.  Error  analysis  Is  based  on: 

e The  type  of  bus  message  operation 

f The  status  word(s)  received  from  the  transmitting 
and/or  receiving  terminal  Involved  In  the  opera- 
tion, and 
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TABLE  7.  MESSAGE  ERROR  RESPONSE 
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TABLE  8.  MESSAGE  RETRY  PROCEDURES 


TABLE  9.  RETRY  PROCEDURE  FOR  EACH  MESSAGE  OPERATION 
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— Not  AppllcobTt 

*Fer  Host  ttnlMls  this  case  does  not  exist,  since  thdy  signal  an  error  by  net  returning  a status  word 
**User's  defined  Xetiy, 


• The  Internal  status  register  (ISR)  In  the  Master 
BCIU  Indicating  If  a status  word  was  received 
from  each  terminal  involved  In  the  operation. 

The  method  of  retry  Is  based  on  specifications  of  the  system 
designer,  the  type  of  message  operation,  and  the  manner  In  which  the 
error  Is  detected.  The  six  classes  of  retry  are  defined  In  Table  8. 

A Class  I retry  is  specified  by  Including  a non-zero  value 
In  the  retry  field  of  the  bus  Instruction.  This  Is  the  standard  retry 
procedure  for  most  messages.  It  Is  performed  automatically  by  the 
Master  BCIU  without  processor  Intervention. 

A Class  II  or  Class  III  retry  Is  specified  by  Including  a 
NO  OP  Instruction  following  the  bus  list  instruction  to  send  the  mes- 
sage. Class  II  (careful  retry)  is  utilized  If  a subsystem  would  be 
degraded  or  function  Improperly  when  a message  Is  repeated.  Class 
III  (sequence  retry)  Is  utilized  when  a series  of  messages  must  be 
successfully  transmitted  for  proper  subsystem  oepratlon,  such  as  to 
arm  the  Station  Logic  Unit  (SLU). 

Classes  IV,  V,  and  VI  are  utilized  with  asynchronous  mes- 
sages, and  depend  on  the  terminals  Involved  and  whether  or  not  they 
recognize  that  a message  error  occurred.  As  with  Class  II,  the  re- 
ceiver could  be  harmed  by  a repeated  message.  In  addition,  the 
transmitter,  if  not  advised  of  the  error,  would  send  Its  next  asynch- 
ronous message  when  a repeat  Is  attempted. 

Class  IV  Is  Invoked  when  the  transmitter  need  not  be  re- 
aligned. Class  V Is  used  when  It  Is  uncertain  if  the  transmitter 
saw  the  error  and,  finally.  Class  VI  applies  when  It  is  uncertain  If 
either  the  transmitter  or  receiver  saw  the  error. 


Terminal  failures  are  also  detected  by  self-tests  performed 
within  each  BCIU  and  Remote  Terminal  by  the  micro-controller.  Each 
BCIU  and  RT  while  not  participating  In  data  transfer  on  the  bus,  per- 
forms an  internal  background  self-test.  These  Include  register  data- 
pattem  wraps  and  verification  of  basic  micro-code  operations.  Results 
of  these  tests  are  encoded  Into  the  appropriate  fields  of  the  Built-In- 
Test  Word.  In  addition,  the  master  processor  may  elect  to  perform  a 
coeprehensi ve  self- test  Included  In  the  master  mode  BCIU.  This  con- 
tains all  those  tests  performed  In  background  as  well  as  a full  parity 
sum  check  of  all  micro  Instructions. 
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When  a redundant  element  In  a terminal  (data  bus  Interface  1 
or  2}  or  a terminal  (data  bus  Interface  1 and  2)  Is  declared  as  failed, 
the  master  executive.  If  possible,  maintains  the  system  In  an  opera- 
tional state  by  utilizing  the  redundant  data  bus  path,  or  perform 
backup  or  recovery  operations  by  automatically  switching  to  a redundant 
unit. 

A terminal  failure  Is  Indicated  If  a message  Is  not  success- 
fully transmitted  after  retries  have  been  attempted  on  both  buses. 
Terminal  Failure  Analysis  Is  Invoked  by  the  Configuration  Management 
function  when  It  detects  an  accumulation  of  errors  In  excess  of  a 
parameter  defined  by  the  system  designer  for  the  specific  terminal. 

The  function  of  this  procedure  is  to  confirm  that  the  term- 
inal has  failed  or,  if  possible,  to  clear  the  error  condition.  In 
either  case,  the  results  of  this  analysis  are  reported  to  Configuration 
Management,  which  has  the  responsibility  of  determining  If  communica- 
tions should  be  inhibited  with  the  entire  terminal.  If  additional 
retries  should  be  attempted,  or  If  selected  subsystems  should  be 
declared  as  failed. 

The  analysis  performed  differs  slightly  for  the  different 
types  of  terminals.  The  DAIS  built-in  tests  provide  the  primary 
mechanism  for  the  failure  analysis.  In  addition,  for  a BCIU  there 
exists  processor/BCIU  interface  tests  which  are  exercised.  The  handling 
of  the  Master  BCIU  differs  In  that  it  may  be  accessed  directly  via  PIO 
rather  than  using  mode  commands. 

4.1.5  Configuration  Management 

The  repeated  failure  of  a bus  message  is  reported  to  the 
Configuration  Management  function  for  tabulation  and  analysis.  A 
message  which  succeeds  on  Imnedlate  retry  Is  not  reported.  (In  fact, 
the  processor  Is  not  even  aware  of  the  error  if  a Class  I retry  suc- 
ceeds.) Reported  errors  are  tabulated  against  a terminal  address  with 
separate  counters  accumulating  errors  on  the  two  redundant  communica- 
tions paths. 


The  overall  Interaction  of  the  assorted  system  functions 
Involved  In  declaring  or  responding  to  a device  failure  is  shown  in  , 
sinplifled  form  In  Figure  18.  Configuration  Management  Is  notified  / 
only  after  repeated  errors  and  then  a failure  is  declared  only  after  , 
a critical  threshold  is  reached  or  self  tests  reveal  a hard  failure. 
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The  first  task  of  Configuration  Management  is  to  decide  what 
terminal  to  charge  with  the  error.  While  determination  that  an  error 
occurred  is  primarily  based  on  the  receiver's  status  word  (or  lack  of 
it),  the  error  is  normally  attributed  to  the  transmitting  terminal. 

The  receiver  is  charged  with  the  error  only  in  the  case  that  he  re- 
ports an  error  when  neither  the  Master  processor/BCIU  nor  the  trans- 
mitting terminal  detect  any  anomaly. 


Two  error  counters  are  maintained  by  Configuration  Manage- 
ment for  each  bus  side  of  each  terminal  address.  The  history  counter 
represents  an  accumulated  count  of  errors  since  system  startup.  It 
is  cleared  only  during  startup  or  reconfiguration.  The  current  error 
counter  represents  the  number  of  errors  tallied  since  the  last  suc- 
cessful execution  of  self- test. 

These  error  counters  are  compared  with  Ijvo  threshold  values 
specified  by  the  system  designer  for  the  terminal  address  under  analy- 
sis. If  neither  threshold  is  exceeded,  the  procedure  simply  resumes 
the  normal  retry  sequence.  If  the  current  error  threshold  is  exceeded, 
terminal  failure  analysis  is  initiated  to  either  clear  or  confirm  the 
error  condition.  If  the  history  count  threshold  is  exceeded,  the  ter- 
minal is  flagged  as  failed  for  this  bus  without  any  further  analysis 
or  expenditure  of  overhead. 

When  terminal  failure  analysis  is  invoked,  it  will  cause 
self- tests,  which  are  largely  bus  independent,  to  be  run.  If  these 
tests  and  the  subsequent  BIT  word  analysis  reveal  a serious  error 
condition,  the  entire  device  may  be  flagged  as  failed.  Also,  since 
terminal  failure  analysis  can  be  a lengthy  procedure,  the  system  must 
protect  itself  from  excessive  testing.  A device  will  be  flagged  as 
failed  if  terminal  failure  analysis  is  invoked  for  it  twice  in  the 
same  minor  cycle. 

Another  condition  under  which  an  entire  device  is  failed  is 
that  of  a failure  on  one  bus  when  the  Master  previously  had  been 
failed  on  the  other  bus. 


When  an  entire  device  is  flagged  as  failed,  Configuration 
Nanageaent  will  perform  one  of  several  actions  depending  on  the  type 
of  device.  If  a remote  terminal  Is  failed.  Mission  Application  Soft- 
ware will  be  notified  by  woy  of  the  Subsystem  Status  Monitor,  so  that 
aporopriate  recovery  or  backup  of  the  failed  subsystem  may  be  activa- 
ae4.  Alto,  ttie  bue  massages  to  that  terminal  are  "NO-OPed",  e.g.  the 
lermfeal  dpclared  at  "down".  Terminals  that  have  been  teclared  as 
'tkBPr*  bp  eprfigwratlon  ■enagemant  are  periodically  polled.  If  the 
1 1 -leeTtn . self  test  of  the  terminal  Is  Initiated.  If  the 
< dariared  et  "up"  the  messages  to  that  terminal  are  re- 
90  mmhtMim  software  notified  of  the  recovered  device. 


FIGURE  18.  CONFIGURATION  MANAGEMENT  INTERACTIONS 


4.1.6 


Monitor  Management 


When  a Monitor  Processor  Is  Included  In  a configuration. 

It  Is  loaded  with  a copy  of  the  Master  Executive  and  that  subset  of 
application  tasks  which  are  deemed  to  be  mission  critical.  The  Master 
Executive  maintains  an  Internal  flag  to  Indicate  whether  It  Is  oper- 
ating In  Mi»ster  or  Monitor  mode.  The  Monitor  BCIU  Is  operated  In 
remote  mode,  since  only  one  unit  may  control  the  bus  at  any  one  time. 
This  Is  a critical  point  since  the  likely  outcome  of  two  units  attempt- 
ing to  control  the  bus  Is  that  both  will  appear  to  have  experienced  a 
serious  Internal  failure. 

The  Master  Processor  periodically  (as  part  of  the  Synchron- 
ous Instruction  List)  sends  messages  to  the  Monitor  updating  the  con- 
figuration table,  so  that  the  Monitor  has  as  current  a view  of  the 
system  as  possible  should  It  be  necessary  to  assume  control.  An 
assortment  of  other  messages  are  sent  by  various  functions  in  the 
Master,  including  minor  cycle  synchronization  messages.  A special 
"Takeover"  message  is  sent  from  the  system  backup  function  in  the 
Master  Processor  to  request  the  Monitor  to  assume  control  of  the 
system. 

If  the  Master  has  failed,  it  may  not  be  possible  to  send 
the  “Takeover"  message.  The  Monitor,  therefore,  keeps  track  of  the 
minor  cycle  messages  and  operates  its*  own  timer  to  independently 
determine  when  a minor  cycle  time  expires. 

The  master  is  permitted  to  slip  minor  cycles  up  to  a limit 
of  N minor  cycles  as  determined  by  the  system  designer.  The  Monitor, 
therefore,  assumes  control  if  no  minor  cycle  synchronization  messages 
are  received  for  a time  period  sufficient  for  N + 1 minor  cycles. 

4.1.7  System  Recovery/Backup  Operation 

When  the  system  is  configured  with  a Monitor  processor, 
two  alternate  modes  of  operation  are  available  These  are  the  Backup 
mode.  In  which  control  Is  transferred  to  the  Monitor  Processor,  and 
the  Recovery  mode,  in  which  no  control  transfer  takes  place.  These 
operational  modes  are  activated  automatically  when  certain  failures 
are  detected. 

Backup  Is  activated  when  the  Master  Processor/BCIU  falls. 

The  Monitor  Processor  takes  control  of  system,  places  its  BCIU  In 
master  mode  and  flags  itself  as  Master.  Mission  critical  applications 
are  then  activated;  the  pilot  is  notified  of  the  situation;  and  Normal 
System  Operation  Is  entered.  Note  that  the  Backup  mode  is  the  complete 
Normal  System  Operation  for  a one  processor  system. 


Backup  is  also  activated  if  a remote  processor/BCIU  fails. 
This  is  necessary  since  Interdependent  mission  application  software 
modules  are  distributed  across  the  Master  and  Remote  Processors.  The 
loss  of  any  one  of  them,  therefore,  causes  improper  operation  of  the 
others. 

Recovery  is  activated  when  a failure  of  the  Monitor  Proces* 
sor  is  detected.  The  Master  attempts  to  shut  down  the  Monitor  to 
prevent  him  from  erroneously  attempting  to  assume  control  of  the  bus. 
The  pilot  is  advised  of  the  situation  and  normal  system  operation 
resumed.  Note  that  this  is  a very  rapid  operation  and  the  complete 
system  functions  are  maintained.  The  only  loss  is  that  Backup  is  no 
longer  available  as  an  alternate  mode  of  operation. 

As  noted  above,  the  pilot  is  notified  when  either  Backup  or 
Recovery  is  activated.  Normally,  the  pilot  will  then  execute  the 
reconfiguration  procedure  at  a future  convenient  time,  as  determined 
by  mission  requirements  and  other  external  factors. 

4.1.8  System  Reconfiguration  Operation 

When  the  pilot  receives  the  indication  that  a processor/BCIU 
has  failed,  the  system  will  have  already  transitioned  itself  to  the 
Backup  or  Recovery  mode  of  operation.  He  has  the  option  of  depressing 
the  corresponding  power  enable  button  on  the  Processor  Control  Panel 
(PCP)  to  power  down  the  failed  unit  and  prevent  it  from  interfering 
with  the  operational  system  elements.  If  the  processor  is  left  powered 
up,  the  system  will  attempt  to  determine  if  and  when  the  unit  recovers 
and  advise  the  pilot  a reconfiguration  mtiy  be  attempted. 

The  pilot  selects  a convenient  time  consistent  with  mission 
requirements  and  initiates  the  reconfiguration  by  pressing  the  START 
or  LOAD  button.  This  will  cause  an  INFLIGHT  RESTART  as  defined  in 
section  4.1.1  and  result  in  the  system  making  maximum  use  of  the 
operational  resources. 


1 
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The  DAIS  architecture  possesses  specific  characteristics 
which  facilitate  the  adaptability  of  the  system  to  various 
applications*  as  well  as  supporting  effective  Incremental  Integration 
and  test  of  the  DAIS  core  elements.  These  key  characteristics 
are  discussed  In  the  following  sections. 

Specific  features  in  the  DAIS  system  which  allow  adaptation 
of  the  core  elements  to  a specific  avionics  system  configuration  are 
presented  below. 

4.2.1  Bus  Devices 

The  basic  message  structure,  data  format  and  command-response 
protocol  required  for  the  multiplex  system  Is  described  In  Section 
4.1.2.  The  message  protocol  Is  defined  as  that  sequence  of  bus 
messages  required  to  perform  normal  multiplex  synchronous  and 
asynchronous  operations,  and  to  support  message  error  detection  and 
recovery  process.  This  definition  of  the  coirmand  formats  allow  up 
to  32  different  addressed  devices  to  be  Implemented  on  the  multiplex 
system.  DAIS  has  further  expanded  this  definition  to  allow  up  to 
four  processors/BCIU,  and  then  up  to  28  remote  terminal  devices. 

The  system  designer  would  define  the  specific  hardware 
configuration  (number  of  processors/BCIUs,  number  of  RTs  to 
Interface  with  the  avionic  sensor  and  subsystems  using  the  standard 
Interface  Modules  (IMs)  or  unique  IMs  If  required).  The  system  designer 
would  then  define  the  sensor  Inputs/outputs  as  data  bus  messages, 
and  Input  this  Information  to  PALEFAC.  PALEFAC. would  generate  the 
Executive  bus  Instruction  list  tables  accordingly,  which  will  direct 
the  messaoes  to  the  proper  processor  containing  the  application 
software  (e.g.  EQUIPS  module)  which  would  process  the  sensor/subsys- 
tem data. 

The  DAIS  architecture  Is  readily  adaptable  to  various 
numbers  of  devices  on  the  bus,  and  provides  the  tools  to  automatically 
generate  and  direct  the  messages  to  the  proper  application  software  In 
one  of  the  processors. 

4.2.2  Processor/Bus  Controllers 

The  architecture  provides  the  capability  to  expand  or 
reduce  the  number  of  processors/BCIU  for  a specific  application.  The 
system  designer  would  perform  trade-offs  In  determining  the  number  of 
processors/BCIU  required  considering  mission  requirements,  reliability 
and  availability. 
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The  system  designer  would  define  the  mission  software 
application  modules  (Inputs,  outputs,  and  algorithms)  based  upon 
the  mission  requirements  and  avionic  suite.  The  application 
progranmer  would  develop  the  application  modules  using  the  J73/I 
language  and  mission  software  standards.  Based  upon  the  application 
execution  times,  memory  size,  data  access,  comsubs,  and  the  bus 
message  traffic,  the  system  designer  would  then  partition  the 
application  tasks  among  the  processors  using  PALEFAC.  PALEFAC 
would  produce  the  tables  for  the  master  executive,  and  local 
executive  required  for  run  time  execution  of  the  application  soft- 
ware In  the  specific  configuration  of  processors/bus  controllers. 

4.2.3  Remote  Terminal  (RT)/Interface  Modules  (IMs) 

The  RT  has  a modular  and  programnable  design  to  provide 
flexible  partitioning  of  the  data  messages  to  the  appropriate 
sensors/subsystems,  and  signal  conditioning  required  by  different 
nunbers  and  mixes  of  subsystem  signals.  This  Is  accomplished  as 
follows: 

The  Timing  and  Control  Unit  (TCU)  In  the  RT  performs 
all  of  the  timing,  control,  buffering,  decoding  and  checking 
required  to  receive  or  transmit  Information  from  the  data  bus  and 
transfer  that  Information  as  outputs  or  Inputs  from  the  RT,  via  the 
Interface  Nodules  (IN).  The  TCU  contains  a programmable  device 
which  controls  the  mapping  of  c^ach  data  word  In  the  RT.  The 
Interface  between  the  TCU  and  xMs  Is  standardized  and  contains  the 
signals  required  to  allow  TCU  to  select  the  Individual  modules.  Therefore, 
all  IN  slots  can  accept  all  IN  types. 

Each  RT  will  Interface  with  different  numbers  and  mixes 
of  sensor/subsystem  signals  for  each  specific  system  configuration. 

This  Is  accomplished  by  Inserting  the  proper  number  and  type  of 
Interface  modules  Into  the  IN  slots  in  the  RT  housing  and  appropriate 
RON  programing  In  the  TCU.  If  required,  a special  Interface 
module  can  be  designed  to  Interface  with  an  existing  subsystem  with 
a unique  Interface. 

The  functions  of  the  RT  can  also  be  embedded  In  a sensor 
or  subsystem,  so  that  the  Interface  of  the  sensor  or  subsystem  Is 
directly  with  the  multiplex  data  bus.  Functionally,  the  embedded 
RT  would  respond  to  commands  received  on  either  data  buses  the  same 
as  an  RT. 

4.2.4  Applicable  Software 

The  DAIS  System  Architecture  Is  designed  to  allow  modular 
Implementation  of  specific  systems  by  using  the  required  elements 
of  the  DAIS  system,  both  hardware  and  software.  Given  that  the  set 


of  multiplex  equipment  has  been  chosen  for  Interfacing  to  the 
external  world  (sensors  and  Controls  and  Displays  equipment),  the 
design  of  the  processing  system  can  begin.  The  Application 
Software  Is  Initially  designed  as  If  It  will  exist  In  one  large 
virtual  processor  with  as  much  memory  space  and  execution  time 
available  as  the  sum  of  the  flight  processors  to  actually  be 
used  In  the  system.  After  the  data  Interfaces  have  been  defined 
to  the  outsidie  world  (multiplex  bus  messages),  and  the  functional 
performance  required  of  the  Application  Software  has  been 
Identified,  the  layout  of  Compool  Blocks  and  tasks  can  begin. 

Compool  biocks  are  the  data  conmunl cation  paths  between 
the  Application  Software  and  the  external  world  (over  the  multiplex 
bus),  as  well  as  between  the  Application  Software  tasks.  Tasks  are 
the  processing  elements  In  the  Application  Software  which  collectively 
perform  the  Avionics  processing  function.  Tasks  access  the  Compool 
Blocks  through  calls  upon  Executive  services  (such  as  READ  and 
WRITE)  and  operate  upon  the  contents  of  the  COMPOOL  BLOCK  as  local 
data  for  processing  purposes. 

After  the  functions  of  the  Application  System  have  been 
designed  In  terms  of  Tasks  and  Compool  Blocks,  and  the  application 
software  has  been  tested  on  the  Host  Processor  as  the  single 
virtual  processor,  partitioning  of  the  Application  System  onto  the 
flight  processors  begins.  This  partitioning  Is  Illustrated  In 
Figures  19  and  20  for  a two  and  three  processor  system  configuration 
respectively. 

This  capability  to  easily  partition  the  Application 
Software  across  a set  of  flight  processors  Is  a direct  result  of 
the  use  of  the  DAIS  Executive  to  provide  general  I/O  control  for 
all  communications  on  the  multiplex  bus  (between  processors  as 
well  as  to  the  external  world),  and  the  use  of  PALEFAC  to  build  the 
data  base  which  Is  then  used  by  the  Executive  to  control  system 
communications.  The  use  of  the  Executive  and  PALEFAC  results  In 
an  automatic  partitioning  of  the  Compool  Blocks  on  to  processors 
based  upon  the  partitioning  of  Tasks,  and  which  Tasks  use  which 
Compool  Blocks.  If  a Compool  Block  Is  used  for  conmunlcatlons 
between  tasks,  and  the  tasks  are  split  Into  two  or  more  processors, 
the  System  will  automatically  generate  a copy  of  the  Compool  Block 
at  each  processor,  as  well  as  generating  the  multiplex  bus  message 
to  update  all  other  copies  when  one  copy  Is  updated  . 

The  system  will  also  automatically  generate  the  multi- 
plex bus  messages  required  to  connect  the  Compool  Blocks,  which 
Interface  to  the  outside  world,  to  the  devices  on  the  multiplex  bus. 
All  multiplex  bus  messages  may  be  declared  as  synchronous  with  a 
period  and  phase,  and  If  not  so  specified,  the  System  will  auto- 
matically generate  asynchronous  updates  of  the  bus  messages  when  a 
copy  Is  updated. 


— ■* 
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MASTER 


FIGURE  19.  MISSION  SOFTWARE  PARTITIONING  - THREE  PROCESSORS 


MASTER 


FIGURE  20.  MISSION  SOFTWARE  PARTITIONING  - TWO  PROCESSORS 


4.2.5 


Interface  “Standards" 


L 


4. 2. 5^1  DAIS/1 553A  Message  Protocol 

As  discussed  previously.  MIL-STD-1553A  defines  the  basic 
message  structure  and  command' response  protocol.  In  order  to 
properly  handle  detected  message  errors  and  other  DAIS  system 
features.  DAIS  further  expanded  the  definition  of  1553A  and  defined 
a set  of  procedures,  designated  the  system  control  procedures,  that 
defines  the  mechanism  to  support  bus  operations  and  message  error 
and  terminal  failure  detection  and  recovery  process.  This  composite 
definition  of  DAIS/1553A  protocol  establishes  a "standard".  If  .a 
sensor/subsystem  device's  bus  Interface  conforms  to  this  "standahl". 
It  would  be  fully  compatible  with  the  DAIS  System  Architecture. 

4. 2.5. 2 Executive  Application  Software  Services 

As  discussed  previously,  the  DAIS  Executive  has  been 
designed  from  the  point  of  view  of  supplying  a set  of  standard 
services  to  Application  Software.  These  services  are  provided  to 
the  Application  System  through  a set  of  software  Interfaces  »yh1ch 
are  fully  specified  and  are  Application  Invariant.  The  result  of 
standardization  of  the  Interface  Is  that  the  Executive  is  truly 
Application  Independent  and  can  be  used  as  a modular  piece  of  the 
DAIS  System. 

4.2.6  Portability 

The  DAIS  Mission  Software  approach  has,  from  the  very 
beginning,  been  conceived  of  an  easily  retargetable  system.  The 
single  most  Important  feature  that  allows  this  capability  Is  the 
development  of  more  than  97%  of  the  DAIS  Executive  Software  In 
JOVIAL  J73/I  (the  only  routine  written  In  assembly  language  are 
processor  dependent  I/O  operations,  register  manipulation  operations 
and  lowest  level  Interrupt  handlers).  All  of  the  DAIS  Application 
Software  Is  Implemented  In  JOVIAL  J73/I.  A striking  demonstration 
of  the  portability  of  the  DAIS  Mission  Software  Is  the  fact  that  It 
executes  both  on  the  DAIS  processor  and  on  the  DEC-System-10,  the 
host  processor  facility.  In  fact,  standalone  module  testing  and 
Initial  subsystem  Integration  testing  of  Application  Software  Is 
performed  on  the  Host  Processor.  This  Is  possible  since  the 
JOVIAL  J73/I  Compiler  has  a code  generator  for  both  the  DEC-System-10 
and  the  DAIS  processor,  which  points  out  the  ease  of  retargetablllty 
of  the  DAIS  Software  System. 
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4.2.7  Redundancy 

DAIS  provides  redundancy  In  the  system  architecture 
which  can  be  employed  to  provide  backup  and  recovery  to  complete 
mission  functions  In  spite  of  hardware  failure.  The  areas  which 
can  be  used  for  redundancy  are: 

a.  Dual  redundant  data  bus  Including  redundant  bus 
Interface  modules  In  the  BCIU  and  RT. 

b.  System  can  employ  dual  redundant  RTs  for  a specific 

subsystem. 

c.  Multifunction  keyboard  and  associated  Data  Entry 
Keyboard  can  be  used  as  a backup  to  the  Integrated  Multifunction 
Keyboard  and  associated  Data  Entry  Keyboard. 

d.  Raster  displays  can  serve  as  backup  to  each  other. 

e.  A processor/BCIU  can  be  designated  as  monitor,  serve 
as  backup  to  the  master  processor/BCIU. 


5.0 


Support  Facility 

The  purpose  of  the  AVSAIL  support  facility  is  to  test  and 
evaluate  the  DAIS  architecture  and  a representative  set  of  core 
elements.  The  support  facility  provides  a real  time  simulation  of 
a military  aircraft  performing  an  operational  mission.  The  simulation 
generates  the  Interface  signals  between  the  simulated  aircraft 
sensor  suite  and  the  DAIS  system  so  that  the  avionic  equipment  Is 
subjected  to  a data  signal  environment  which  Is  nearly  Identical  to 
actual  flight.  A simulated  cockpit  is  Included  as  part  of  the 
simulation  for  realistic  evaluation  of  the  avionic  system. 

The  support  facility  for  DAIS  consists  of  a Software 
Test  Stand  (STS)  and  an  Integrated  Test  Bed  (ITB) . The  Software  ' 
Test  Stand  provides  a capability  to  test  and  check  out  the  mission 
software  resident  in  the  DAIS  flight  processors.  The  Integrated 
Test  Bed  provides  the  capability  to  test  the  DAIS  core  elements 
which  Include  the  mission  software,  the  DAIS  processors,  the 
multiplex  bus  system  and  the  cockpit  control  and  displays.  Both 
the  STS  and  ITB  utilize  a complex  of  digital  computers  consisting 
of  a Digital  Equipment  Corporation  (DEC)  DEC-10  and  a number  of 
DEC  PCP  11  series  computers. 

Simulation  software  resident  in  the  DEC-10  was  developed 
to  provide  real  time  simulation  of  a military  aircraft  in  an 
operational  environment  Including  the  aircraft  dynamics,  the  aircraft 
sensors  and  weapon  targets.  The  simulation  Is  driven  from  the 
cockpit  by  an  operator  acting  as  a "pilot".  The  simulated  cockpit 
Is  equipped  with  control  and  displays  so  that  the  various  modes  of 
a mission  may  be  "flown"  by  the  "pilot"  with  an  out-the-window 
background  scene. 

The  support  hardware  and  software  provides  Interfaces 
between  the  DAIS  elements  under  test  and  the  DEC-10  host 
simulation  software.  The  support  facility  provides  the  capability 
to  set  up  a test,  conduct  a simulation  and  record  data  from  both 
the  DAIS  elements  and  the  simulation.  During  a simulation, 
sufficient  test  data  Is  displayed  In  real-time  to  Indicate  that  the 
system  Is  operating  satisfactorily  to  provide  presentation  of  test 
results  for  observing  systems  performance. 

The  support  facility  Is  comprised  of; 

1 . STS  Support  Hardware 

2.  STS  Support  Software  and  PDP-11  Processors 

3.  ITB  Support  Hardware 

4.  ITB  Support  Software  and  PDP-11  Processors 

5.  Host  Simulation  Processor,  DEC-10 

6.  Simulation  Software 

7.  System  Test  Software 

8.  Picture  System 

9.  Picture  System  Software 
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5.1 


System  Configuration 


The  support  facility  functional  diagram  is  shown  in  Figure 
21  and  consists  of  STS  & ITB  hardware  and  software  both  sharing  the 
Host  Simulation  Processor  and  the  DAIS  cockpit.  Support  software  is 
resident  in  the  DEC-10  and  in  the  PDP-11  Processors. 

5.1.1  Integrated  Test  Bed  (ITB) 

The  Integrated  Test  Bed  (ITB)  block  diagram  is  shown  in 
Figure  22  and  is  comprised  of  the  support  facility  and  DAIS  core  ele- 
elements.  The  support  facility  simulates  all  the  equipment  and 
environment  external  to  the  DAIS  processor  with  the  resident 
mission  software,  DAIS  multiplex  system,  and  DAIS  controls  and 
displays.  The  ITB  support  facility  is  comprised  of  support  hardware, 
support  software  resident  in  the  PDP-11  processor,  the  simulation 
software  resident  in  the  DEC-10  host  simulation  processor,  the 
DAIS  simulated  cockpit,  and  an  out-the-window  picture  system. 

The  support  hardware  provides  the  interfaces  between  the 
simulation  and  the  DAIS  core  elements.  The  interface  includes: 

(1)  the  multiplex  bus  messages  which  drive  the  mission  software,  (2) 
the  performance  monitoring  of  the  multiplex  bus  traffic  and  the 
internal  operation  of  the  mission  software  in  the  DAIS  processors, 

(3)  the  cockpit  controls  and  backup  instruments,  and  (4)  the  out- 
the-window  picture. 

The  support  software  controls  and  manages  the  support 
hardware  and  provides  the  means  to  link  the  DEC-10  simulation 
software  with  the  DAIS  elements.  The  support  software  also  provides 
the  performance  monitor  and  control  functions  which  are  related  to 
test  set-up,  control  and  data  collection  for  post-test  analysis. 

The  host  simulation  processor  is  a commercial  DEC-10 
complex.  The  simulation  software  generates  the  real  world 
environment  external  to  the  DAIS  processors  in  real  time.  The 
simulation  is  driven  by  the  DAIS  cockpit  flight  controls  so  that 
an  operator  can  "fly"  the  simulation. 

An  out-the-window  picture  system  provides  a symbolic 
background  scene  outside  of  the  cockpit  so  that  the  "pilot" 
operator  will  experience  the  visual  orientation  of  flight  with 
respect  to  IP's,  targets  and  runways.  The  picture  system  also 
provides  the  option  for  displaying  the  HUD  symbology  overlayed  on 
the  background  scene. 

A pictorial  representation  of  ITB  is  shown  in  Figure  23. 
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INTEGRATED  TEST  BED  (ITB) 
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FIGURE  21.  SUPPORT  FACiLin  FUNCTIONAL  DIAGRAM 
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FIGURE  22.  INTEGRATED  TEST  BED  (ITB)  FUNCTIONAL  BLOCK  DIAGRAM 


A set  of  system  test  software  Is  resident  In  the  host 
simulation  processors,  the  IT6  PDP-11  processors  and  the  DAIS 
processors  for  system  readiness  test  prior  to  performing  operational 
runs  and  for  diagnosing  faults. 

5.1.2  Software  Test  Stand  (STS) 

A block  diagram  of  STS  Is  shown  In  Figure  24.  The  STS  system 
system  Is  similar  In  structure  to  the  ITB,  and  shares  utilization 
of  the  DAIS  cockpit  and  controls  and  displays,  and  real  time 
simulation  software  on  the  DEC-10  complex.  Cotnnon  support  hardware 
and  software  Is  used  In  both  ITB  and  STS. 

STS  Is  generally  utilized  to  test  mission  software 
(e.g.  executive)  and  the  support  software  when  operation  with  the 
real-time  simulation  models  and  DAIS  cockpit  is  not  required. 

5.1.3  Physical  Configuration 

The  support  facility  Is  configured  as  laboratory  equip- 
ment. 

The  floor  layout  and  rack/console  configuration  for  STS 
and  ITB  are  shown  as  follows: 

!a)  STS/ITB  Floor  Layout  - Figure  25 

b)  STS  Test  Control  Center  - Figure  26 

c)  STS  Equipment  Racks  - Figure  27 

d)  ITB  Test  Control  Center  - Figure  28 

e)  ITB  Equipment  Racks  - Figure  29 
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FIGURE  26.  SOFTWARE  TEST  STAND  TEST  CONTROL  CENTER 


FIGURE  27.  SOFTWARE  TEST  STAND  RACKS 


5.2  ITB  Support  Hardware 

The  ITB  hardware  consists  of  the  following  subsystems: 

' c / 

5.2.1  Universal  Remote  Terminal 

The  Universal  Remote  Terminal  (URT)  simulates  the  operation 
of  a set  of  remote  terminals  (32  RTs  maximum).  The  URT  receives  or 
transmits  data  between  the  DAIS  multiplex  data  bus  and  the  PDP  11/40 
processor.  The  URT  provides  the  same  Interface  to  the  DAIS  multiplex 
as  a Remote  Terminal,  except  the  URT  simulates  up  to  32  RTs. 

The  URT  Is  set  up  and  controlled  by  the  SSDF  software  In 
the  POP  11/40  by  loading  the  URT  registers  and  RAMs.  In  r«al  time 
operation,  the  URT  performs  the  following: 

1.  Transfers  the  DAIS  multiplex  data  to/from 
the  POP  11  for  each  message  operation  (con- 
troller-to-terminal,  termlnal-to- terminal, 
and  termlnal-to-controller)  based  upon: 

• RT  address/subaddress 

• Transmit/receive  bit 

• Word  count 

• PDP  11  memory  address 

2.  Responds  to  mode  commands  received  on  the 
DAIS  multiplex  data  bus.  The  URT  has  the 
capability  to  generate  an  Interrupt  to  the 
POP  11  upon  receiving  the  following  mode 
commands: 

• MTU  1 or  2 shutdown 

• MTU  1 or  2 shutdown  override 
e Reset  bit  word 

e Initialize  terminal 

• Initiate  serial  channel  I/O 

• Minor  qycle  sync 

3.  Capability  to  set/reset  bits  In  the  serial 
channel  activity  register  and  module  error 
register,  and  the  BIT  register  for  each 
simulated  RT. 

4.  Capability  to  Inhibit  the  status  response  to  ^ 
any  receive  command. 
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5.2.2  Simulated  Subsystem  Interface  Unit 

The  Simulated  Subsystem  Interface  Unit  (SSIU)  provides  the 
Interface,  control,  fnd  data  transfer  functions  required  to  Interface 
a set  of  remote  terminals  (RTs)  to  a POP  11  unibus.  Each  RT  Inter- 
faces to  the  SSIU  via  a Facility  Interface  Module  (FIM)  which  Is 
specially  designed  for  this  purpose.  Figure  30  Is  an  Interface  block 
diagram  Illustrating  the  SSIU  Interconnection. 

The  SSIU  provides  the  Interface  for  the  simulated  sensor 
suite  that  In  actual  operation  would  be  Interfaced  by  up  to  sixteen 
fully  populated  RTs  with  any  complement  of  Interface  Modules  (IMs). 

A FIN  occupies  a single  RT  slot  and  responds  to  any  slot  addressed  by 
an  address  which  defines  the  IM  slot  and  IM  channel  for  which  the  jata 
were  actually  Intended.  The  SSIU  uses  this  address  as  a pointer  to 
store  and  retrieve  data  from  unibus  memory  In  preselected  locations 
which  are  mapped  to  correspond  to  the  RT  configurations  being  simu- 
lated. 

The  SSIU  uses  a POP  11  unibus  memory  that  can  support  a 
Direct  Memory  Access  (DMA)  data  rate  of  at  least  1 MHz  for  each  16 
bit  word  and  operate  In  a burst  mode  (dedicated  unibus)  for  up  to  34 
microseconds.  Other  features  of  the  SSIU  Include: 

1.  At  the  end  of  each  data  block  written  Into 
unibus  memory,  transferring  a pointer  by 
DMA  to  a preselected  location  defining  the 
starting  address  of  the  data  block; 

2.  Providing  an  Interrupt  at  the  end  of  pre- 
selected messages; 
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3.  Providing  an  Interrupt  for  several  types  of 
error  conditions. 


Set  up  of  the  SSIU  memory  and  control  registers,  and  monitor  and  con- 
trol of  the  SSIU  during  operation  are  provided  via  unibus  Programmed 
Input/Output  (PIO). 

5.2.3  Bus  Monitor  Unit 

The  Bus  Monitor  Unit  (BMU)  receives,  records  and  break- 
points on  selected  messages  received  on  the  DAIS  multiplex  data  bus. 
The  BMU  stores  the  received  messages  Into  the  PDP  11/40.  The  BMU 
Interfaces  with  the  DAIS  multiplex  data  bus  and  monitors  for  data 
messages  (controller- to-termlnal,  termlnal-to-controller,  and  ter- 
minal- to-  terminal  messages)  and  mode  commands.  The  BMU  operates  In 
either  the  automatic  mode  or  manual  mode. 
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The  BMU  is  scw  up  and  controlled  by  the  PMC  software  in  the 
POP  11/40.  The  BMU  has  the  capability  to  provide  selective  monitoring 
as  follows: 

1.  Record  the  bus  traffic  beginning  at  a specified 
breakpoint  and  record  for  a specific  number  of 
words . 

2.  Record  the  bus  traffic  beginning  at  a specified 
breakpoint  and  record  for  a specified  length  of 
time. 

3.  Record  the  bus  traffic  beginning  at  a specified  ^ 
breakpoint  and  record  until  a second  specified 
breakpoint  is  reached. 

4.  Record  the  bus  traffic  beginning  at  a specified 
breakpoint  and  record  only  a specified  message. 

5.  Record  all  bus  traffic,  only  the  control  words 
(command  and  status),  or  only  '.ne  data  words. 

6.  Transmit  a message. 

The  BMU  also  has  a manual  control  function  which  can  record 
all  bus  traffic,  only  the  control  words  (command  and  status),  only 
the  data  words,  or  only  the  message  gap  time.  The  manual  modes  are 
controlled  directly  from  the  BMU  front  panel. 

5.2.4  Super  Control  and  Display  Unit  (SCADU) 

The  Super  Control  and  Display  Unit  (SCADU),  in  conjunction 
with  the  PMC  software  provides  the  ITB  or  STS  users  with  the  capa- 
bility to  monitor  and  control  the  software  running  in  the  DAIS  proces- 
sor (AN/AYK-15).  The  SCADU  sets  up  and  is  controlled  by  the  PMC 
software  to  collect,  store,  and/or  breakpoint  on  the  data  received 
from  the  DAIS  processor  (Table  10);  and  then  halt  the  DAIS  processors 
and/or  BCIUs,  and  interrupt  the  PMC  PDP  11/40. 

The  DAIS  processors  make  available  to  the  SCADU  Information 
accessed  or  stored  into  the  processor's  memory.  Based  upon  the  proces- 
sor's memory  controller  micro-code  addresses,  the  SCADU  determines 
which  data  (Table  10)  Is  being  received  from  the  processor  over  the 
parallel  multiplex  data  bus.  The  SCADU  then  selectively  monitors  and 
stores  this  data. 

The  PNC  software  sets  up  the  SCADU  for  real  time  operation 
by  loading  the  SCADU  control  RAMs  with  specific  micro-programmed 
monitor  and  control  actions.  The  SCADU  then  performs  one  or  more  of 
the  following  monitor  functions: 


TABLE  10.  DATA  AVAILABLE  TO  SCADU  FROM  AN/AYK-15  PROCESSOR 


1.  Monitor  all  instructions  addresses. 

2.  Monitor  a specific  Instruction  (Op-code). 

3.  Monitor  all  jump  Instructions  which  cause  a 
branch. 

4.  Monitor  all  memory  stores. 

5.  Monitor  all  memory  accesses. 

6.  Monitor  all  Interrupt  occurrences. 

7.  Monitor  all  DMA  occurrences. 

The  SCADU  also  performs  one  or  more  of  the  following  control 

actions: 

1.  Breakpoint  (halt)  upon  occurrence  of  one  of  the 
specific  functions  above. 

2.  Log  the  data  in  SCADU  buffer  (trace)  with  a time 
tag. 

3.  Compare  the  function  with  user's  specific  value 
(fixed  point  or  floating  point  numbers)  and 
breakpoint. 

4.  Halt  processors  and  BCIUs. 

5.  Interrupt  PDP  11/40. 

6.  Start,  stop,  or  reset  the  time  tag  timer. 

After  the  appropriate  control  actions  have  occurred,  the 
PMC  software  reads  the  data  collected  in  the  SCADU  buffer,  and  reinitiates 
the  same  or  a new  operation. 

5.2.5  Console  Intelligence  Unit 

The  Console  Intelligence  Unit  (CIU),  In  conjunction  with  a 
RS-232  Interface  with  the  PMC  PDP  11/40,  DEC-10,  and  the  Hazeltine 
terminals,  provides  the  means  to  control,  and  load/change  DAIS  proces- 
sor registers  and  memory.  The  CIU  Is  supplied  by  the  DAIS  processor 
vendor  to  support  the  debug  and  test  the  mission  software  under 
non-real  time  conditions.  The  functions  the  user  Is  able  to  perform 
are: 


1.  Clear  Processor 

10. 

Clear  all  Breakpoints 

2.  Halt  Processor 

11. 

Set  a Breakpoint 

3.  Toggle  Memory  Protect 

12. 

Step  Processor 

4.  Read  Instruction  Counter 

13. 

Execute  Processor 

5.  Load  Instruction  Counter 

14. 

Load  Tape  Image 

6.  Read  Register 

15. 

Write  Tape  Image 

7.  Load  Register 

16. 

Stutter  Mode 

8.  Read  Memory 

17. 

DEC  to  Cassette 

9.  Load  Memory 

18. 

Cassette  to  DEC 
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In  the  "Local  Mode",  console  comnands  are  Issued  from  the  Kazeltine 
keyboard.  When  under  control  of  the  0EC>10  or  PMC  POP  11/40*  the  CIU 
is  in  the  "Remote  Mode".  The  DEC-10  or  PMC  POP  11/40  functionally 
.interfaces  with  the  CIU  similar  to  the  Hazeltine  terminals.  This 
allows  the  Hazeltine  terminal  fwictions  to  be  performed  at  tiie  OEC-10 
for  loading,  or  POP  11/40  under  PMC  software  control. 

5.2.6  Hazeltine  Terminals 

The  Hazeltine  terminals,  in  conjunction  with  the  Console 
Intelligence  Unit  (CIU),  provides  interactive  control  of  the  DAIS 
processor  registers  and  memory  as  specified  above.  The  Hazeltine 
terminals  include  the  following: 

1.  Hazeltine  CRT  Display 

2.  Hazeltine  Keyboard 

3.  Hazeltine  Thermal  Printer  ’ 

4.  Hazeltine  Cassette  Tape  Unit  . - 

5.2.7  ITB  Power  Distribution  and  Control 

The  ITB  Power  Distribution  and  Control  System  (PDS)  provixl^ 
simulated  aircraft  electrical  system  control  of  the  power  for  the  DAIS 
core  hardware.  The  PDS  simulates  three  power  sources:  battery, 
master  AC  generator,  and  Ram-Air  Turbine  (RAT).  The  output  of  the 
simulated  power  sources  provides  power  to  two  sets  (AC  and  DC)  elec- 
trical bus  systems:  emergency,  primary,  and  secondary.  Each  DAIS 
core  hardware  element  Is  capable  of  simulated  operation  off  any  one  . 
of  the  electrical  buses.  Also,  each  individual  hardware  element  have 
an  on/off  control.  This  permits  simulated  power  control  or  power  ' 
failure  of  any  one  of  the  power  sources,  simulated  electrical  bpses, 
or  individual  equipments.  The  PDS  includes  provisions  for  software 
control  via  a POP  11/40  of  the  power  sources,  electrical  buses,  or 
individual  equipments. 

The  PDS  system  also  controls,  distributes  and  filters  the 
power  to  each  of  the  DAIS  core  hardware  elements.  The  PDS  system  also 
controls  and  distributes  power  to  the  support  hardware. 

5.2.8  ITB  Test  Control  Center 


The  ITB  Test  Control  Center  (TCC),  shown  in  Figure  28, 
provides  a centralized  point  for  control  of  the  entire  ITB.  The  TCC 
contains  the  terminals  which  can  control  the  PMC  and  SSDF  PDP  11 
processors,  and  the  OEC-10  simulation  models  via  the  PMC.  Both  system 
checkout  and  operation  can  be  controlled  from  the  TCC.  The  TCC  con- 
tains a cockpit  stick  and  throttle  station  which  may  replace  the 
cockpit  and  allow  an  operator  to  "fly"  the  simulation  at  the  TCC.  The 
DAIS  displays  and  the  out-the-window  scene  are  also  displayed  on  CRT 
monitors  at  the  TCC. 
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5.2.9 


Controls  and  Backup  Instruments  System  (CBIS) 

The  CBIS  consists  of  the  DAIS  cockpit  flight  controls  and 
dlspl^s  that  are  not  part  of  DAIS.  The  controls  Include  the  throttle, 
stick,  rudder  control  and  discretes.  The  displays  are  the  basic  flight 
Instruments  Including  the  standby  ADI,  altimeter  and  warning  lights. 

The  CBIS  Interfaces  to  the  IT6  by  means  of  the  backup  C/D  Interface 
unit  which  provides  digital  to  analog  conversions  and  a digital  link 
to  the  SSOF  (URT)  PDP  11/40. 

5.2.10  Four  Port  Buffer  Memory 

A four  port  buffer  memory  is  used  by  the  SSDF  software  for 
data  transfer  between  the  PDP  11  processors  and  the  DEC-10  DMA  window. 
The  four  port  buffer  memory  consists  of  a unibus  port  Interface,  multi- 
plexers, cyclic  priority  system  and  memory.  The  four  port  buffer 
memory  unit  appears  ready  for  use  by  any  port,  with  a worst  case  access 
time  for  any  port  user  of  1 microsecond.  The  memory  operations  that 
way  be  performed  are  read  word,  write  word,  and  write  byte.  There  are 
no  "hardware"  protects  built  Into  this  memory  system,  which  means  that 
If  one  user  stores  Information  In  one  location,  that  same  location  can 
still  be  accessed  by  another  user.  This  memory  may  be  assigned  to  any 
vacant  4K  segment  of  the  PDP  11  unibus  address  map. 

5.2.11  HAS  Super  Control  and  Display  Unit 

The  HAS  Super  Control  and  Display  Unit  (SCADU),  In  conjunc- 
tion with  the  four  port  memory.  Is  used  to  Interrupt  and  pass  control 
Information  (1  data  word)  between  the  PDP  11  processors.  The  HAS 
SCADU  Is  used  by  the  SSDF  (URT)  software  to  interrupt  the  SSDF  (SSIU) 
software  each  minor  cycle. 

5.2.12  1TB  Equipment  Racks 

The  ITB  equipment  racks,  as  shown  In  Figure  29,  Include  the 
ITB  hardware  as  specified  above  as  well  as  power  supplies;  special 
Interface  panels  (multiplex  data  bus  patch  panel,  Processor/BCIU 
breakout  test  patch  panel,  and  CIU/RS-232  patch  panel);  power  control 
panels  and  processor  control  panel. 


-100- 


5.3 


5.3.1 


ITB  Support  Software  and  POP  11  Processors 
Support  software  is  resident  in  the  PDP-11  processors. 
Performance  Monitor  and  Control 


j P®  Performance  Monitor  and  Control  (PMC)  software  resides 

in  a 6T44  System  (POP  11/40)  under  RT  11,  and  is  used  to  set  up,*n- 

"’^ssion  software  resident  in  the  DAIS  processor, 
servicing  from  one  to  four  DAIS  processors  at 
°!?®  simultaneously  monitoring  the  multiplex  bus  traffic 

via  the  BMU  and  recording  selected  DAIS  system  data  for  post  test 
analysis.  kw 

The  PMC  controls  the  SCAOU’s,  CIU's,  and  BMU.  The  DAIS 
Pto«sso«  arc  monitored  and  controlled  through  the  SCADU's  and  the 
ciu  s.  The  PMC  starts  and  stops  the  set  of  DAIS  Processors.  The 
'"^ssion  software  is  loaded  from  or  dumped  to  the 
DEC-10  host  simulation  processor  or  the  PDP  11  processors  under  PMC 
control . 

PMC  sets  up  test  cases  which  define  the  procedures  and 
data  collection  for  a simulation  run.  An  operator  is  able  to  set  up 
the  test  by  means  of  an  interactive  interface  and  the  creation  of  a ^ 
^J^®*  ^^®  control  file  is  correlated  with  the 
DEC-10  simulation  so  that  the  collection  of  test  data  will  proceed  as 
defined  by  the  file  as  the  simulation  progresses. 

The  PMC  supports  the  system  users  in  the  debugging  and 
evaluation  of  mission  software  by  allowing  selective  real  time  and 
non-real  time  gathering  of  data  from  the  DAIS  processor  and  the 
multiplex  data  bus.  The  PMC  provides  a repertoire  of  connands  to  ' 
perform  the  non-real  time  and  real  time  functions  as  follows:  ^ 


1. 

2. 

3. 

4. 

5. 


Manipulate  files  on  the  DEC-10  and  PDP  11  such  as 
rename,  delete,  copy,  etc. 

Load  or  dump  DAIS  processor  mission  software  from 
or  to  the  PDP  11. 

Perform  the  CIU  functions  as  defined  in  paragraph 
5.2.5  when  the  DAIS  processors  arc  halted. 

Start  and  stop  (halt)  the  DAIS  processors  and' 
BCIUs. 

Set  up  the  SCADU  to  perform  specified  functions 
as  defined  in  paragraph  5.2.4  during  real  time 
operation. 
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6.  Set  up  the  bus  monitor  to  record  or  breakpoint, 
as  defined  In  paragraph  5.2.3,  on  specific 
multiplex  data  bus  messages. 

7.  Display,  print,  or  log  the  data  collected  from 
the  bus  monitor,  or  DAIS  processors  via  the 
cm  and  SCADU.  Data  logged  on  a disk  can  be 
analyzed  later  by  a Post  Run  Editor. 

The  PMC  provides  the  capability  to  examine 
or  modify  DAIS  processor  registers  and  memory 
locations  either  with  absolute  or  symbolic 
addresses. 

8.  Provide  Interactive  capability  with  the  DEC-10 
to  set  up  and  run  the  simulation  model. 

The  PMC  provides  the  capability  to  restart  mission  software, 
along  with  the  simulation  models,  from  a system  snapshot  point.  This 
Is  accomplished  by  dumping  mission  software  parameters  at  a specified 
PMC  breakpoint,  and  reloading  these  parameters  to  restart  the  system. 
This  snapshot  and  restart  capability  Is  used  for  repeated  testing  or 
demonstrations  from  a specific  point  In  the  mission  profile. 

5.3.2  Simulated  Subsystem  Data  Formatter  (URT)  Software 

The  Simulated  Subsystem  Data  Formatter  (SSDF/URT)  software 
receives  and  transmits  data  to  and  from  mission  software  via  the  DAIS 
multiplex  data  bus  to  the  real  time  simulation  models  running  on  the 
I DEC-10  via  the  DEC-10  DMA  window.  The  SSDF/URT  sets  up  and  controls 

[ the  URT,  double  buffers  the  data  In  the  four-port  buffer  memory,  and 

; provides  a user  selectable  display  of  the  multiplex  data  bus  messages. 


The  SSDF/URT  software  Is  designed  to  run  on  both  ITB  and 
STS.  The  software  will  automatically  check  for  the  presence  of  CBIS 
and  the  SSDF/SSIU  and  control  the  Interfaces  to  both.  The  SSDF/SSIU 
Indicates  It  Is  on-line  to  the  SSDF/URT  by  setting  a flag  In  the  four- 
port  memory.  This  causes  the  SSDF/URT  to  generate  two  Interrupts  to 
the  SSDF/SSIU  each  models  computational  cycle  via  the  HAS  SCADU.  The 
first  Interrupt  Indicates  the  models  output  data  Is  available  In  the 
four  port  memory  and  the  second  causes  the  SSDF/SSIU  to  swap  the  SSIU 
double  buffers.  The  HAS  SCADU  master  data  register  Is  used  to  dis- 
tinguish between  the  two  Interrupts.  The  SSDF/URT  also  transfers  the 
data  received  by  ^e  SSIU  and  remote  terminals  to  the  DEC-10  DMA 
window. 
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In  non-real  time  mode,  the  SSDF/URT  performs  the  following: 

1.  Memory  management  Initialization. 

2.  Utilizes  user  defined  tables  to  Initialize  the 
URT  rams  and  registers  for  the  specific  mission. 

3.  Initializes  the  four-port  buffer  memory,  HAS 
SCADU,  display  processor,  CBIS  and  keyboard. 

4.  Accepts  user  configuration  commands  to  specify 
the  following: 

a.  Whether  or  not  the  SSDF/URT  software  should 
keep  cycling  the  real  time  models  when 
mission  software  stops. 

b.  Whether  or  not  the  major  and  minor  cycle 

numbers  should  be  passed  to  the  PMC  soft- 
ware via  the  HAS  SCADU.  • ''  ' 

c.  Whether  or  not  the  URT  should  be  set  up  to 

/ respond  to  minor  cycle  messages  to  bus  ' ' 

address  one  (required  for  one  processor  ^ ’ 

configuration  to  respond  to  a dtmty  minor  ’ 
cycle  message). 

5.  Simulate  a mass  memory  device  using  the  PDP  11 
disk  unit  to  allow  loading  of  STS  and  IT6  pro-  ' 
cessors  over  the  DAIS  multiplex  data  bus. 

6.  Initialize  a real-time  clock  to  provide  Inter- 
rupts 32  times  per  second  to  drive  the  real 
time  models. 

The  first  minor  cycle  message  received  or  a user  command 
causes  the  SSDF/URT  to  enter  real  time  mode.  In  real  time  mode,  the 
SSDF/URT  performs  the  following  functions: 

1.  Maintains  and  displays  minor  and  major  cycle 
counts  and  passes  them  to  the  PMC  software  If 
required. 

2.  Generates  Interrupts  to  the  DEC-10  to  cycle 
the  real  time  models  based  on  timer  Interrupts. 

3.  Move  data  received  from  the  URT  and  SSI U to 

the  DMA  window.  f <•  ' 

. , ' ' .1- 1 

4.  Controls  the  swapping  of  the  URT  double  buffers  - 
and  generates  HAS  SCADU  Interrupts  to  the  SSIU 

to  cause  the  SSIU  buffer  swapping. 
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5.  Reads  the  models  output  data  from  the  OHA  to 
the  four-port  and  generate  HAS  SCADU  Inter- 
rupts to  the  SSOF/SSIU  to  cause  the  data  to 
be  read  Into  the  SSDF/SSIU  processor’s  main 
memory. 

6.  Uses  the  timer  and  OEC-10  Interrupts  to  control 
access  to  the  DMA  window. 

7.  Inputs  and  outputs  CBIS  data  (performing  all 
necessary  formatting). 

8.  Handles  mode  command  Interrupts  from  the  URT  as 
required  to  make  the  URT  respond  like  a real 
RT. 

9.  Maintains  displays  of  all  pertinent  information. 

5.3.3  Simulated  Sifcsystem  Data  Formatter  (SSIU)  Software 

The  SSOF/SSIU  software  is  designed  to  run  with  the  SSDF/ 

URT  software.  The  SSDF/SSIU  sets  up  the  SSIU  to  transmit  and  receive 
data  from  and  to  core  memory.  It  moves  the  received  data  from  core 
memory  to  the  four-port  memory  and  move  transmit  data  from  the  four- 
port  to  core.  The  SSDF/URT  will  control  the  buffering  of  the  data 
to/from  the  four-port  from/to  the  DEC-10  DMA  window. 

In  non- real  time  mode,  the  SSDF/SSIU  performs  the  following: 

1.  Memory  management  initialization. 

2.  Utilizes  user  defined  tables  to  initialize 
the  SSIU  rams  and  registers  for  the  specific 
multiplex  bus  messages  and  RT  activity. 

3.  Initializes  the  HAS  SCADU,  display  processor 
and  keyboard. 

4.  Accepts  user  configuration  commands  to 
specify  which  RT  addresses  are  assigned  to 
each  SSIU  slot. 

5.  Set  a flag  Indicating  SSIU  on-line  to  the 
SSDF/URT  software  via  the  four-port  memory. 

The  SSIU  does  not  control  the  entry  Into  real  time  mode  but 
simply  acts  on  SSIU  and  HAS  SCADU  Interrupts.  The  software  can  be 
considered  to  be  In  real  time  mode  when  the  first  Interrupt  Is  received. 
In  real  time  mode,  the  SSDF/SSIU  perforins  the  following: 
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1.  The  HAS  SCAOU  "read"  interrupt  causes  the  ' ' ' 

models  output  da^a  to  be  read  into  the  POP  11  , 

main  memory  buffer  not  being  dsed  by  the  SSIU. 

2.  The  HAS  SCAOU  "swap”  interrupt  causes  the 
SSIU  buffers  to  be  swapped. 

3.  SSIU  interrupts  (only  genef'ated  on  receive 
messages)  cause  the  data  received  to  be  moved 
to  the  four-port  memory  (buffer  A)  and  a HAS 
SCAOU  interrupt  to  be  generated  to  the  SSOF/ 

URT  with  the  four-port  address  of  the  data. 

, ’ 4.  Activity  words  in  the  SSIU  are  set  when 

asynchronous  requests  are  received  from  the  ' 
real  time  models. 

5.  Oisplays  of  pertinent  system  information  will  ^ 
be  maintained. 

5.3.4  Evans  and  Sutherland  Graphics  System 

The  Evans  and  Sutherland  graphics  system  is  used  to  generate 
a cockpit  out-the-window  scene.  The  out-the-window  scene  is  controlled 
by  the  simulation  software  so  that  the  scene  viewed  from  the  cockpit 
has  the  correct  dynamic  orientation  to  synchronize  with  the  simulated 
aircraft  motion.  The  graphics  interface  software  transforms  aircraft 
attitude  and  position  data  obtained  via  the  DEC-10  DMA  window  from 
the  simulation  software  program  into  a form  that  can  drive  the  Evans 
and  Sutherland  graphics  system. 

5.3.5  ITB  PDP  11  Processors 


The  POP  11  processors  include: 

1.  Each  PMC,  SSDF  (URT),  and  SSDF  (SSIU)  processor 

has  a complex  consisting  of  one  DEC  GT-44  * 

PDP  11/40  processor,  and  other  peripherals. 

2.  Evans  and  Sutherland  Graphics  interface  pro- 
cessor consisting  of  a PDP  11  processor. 
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5.4  STS  Support  Hardware 

The  following  hardware  subsystems  are  Identical  to  that 
described  for  the  ITB: 

1.  One  Universal  Remote  Terminal 

2.  One  Bus  Monitor  Unit 

3.  Two  Super  Control  and  Display  Units 

4.  Two  Console  Intelligence  Units 

5.  Two  Hazeltine  Terminals 

6.  One  Four-Port  Buffer  Memry 

7.  One  HAS  SCADU 

The  STS  Power  Distribution  and  Control  (PDS)  system  controls, 
distributes  and  filters  the  power  to  each  of  these  DAIS  core  elements 
and  the  STS  support  harckare. 

The  STS  Test  Control  Center  (TCC),  shown  In  Figure  26, 
provides  a centralized  point  for  control  of  the  entire  STS.  The  TCC 
contains  the  terminals  which  can  control  the  PMC  and  SSDF  PDP  11 
processors,  and  the  DEC-10. 
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STS  Support  Software  and  PDP  11  Processor 

The  PMC  software  for  STS  is  identical  .to  the  ITB  PW  support 
software  as  described  In  paragraph  5.3.1.  ^ , 

The  SSOF  (URT)  software  for  STS  is  identical  to  the  ITB  SSDF, 
(URT)  software  except  interfaces  for  the  SSIU  and  CBIS  are  not  operated. 

The  PMC  PDP  GT-44  System  and  SSDF  (URT)  PDP  GT-44  System  are 
similar  to  the  ITB  PDP  11  processor. 


5.6 


DEC-10  Host  Simulation  Processor 


The  DEC- 10  facility  block  diagram  is  shown  in  Figure  31. 

The  KI  DEC-10  CPU  is  used  with  the  interfaces  and  peripherals  shown 
in  the  block  diagram.  The  DEC-10  facility  is  a conventional  DEC 
configuration  except  for  the  Direct  Memory  Interface  Controller  which 
provides  a DMA  window  access  to  the  DEC-10  memory  for  data  transfer 
between  the  DEC- 10  and  the  POP  11  processors. 
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FIGURE  31.  DEC-10  Host  Simulation  Processor  Configuration 


5.7 


Simulation  Software 


The  Simulation  Software  Is  resident  In  the  DEC-10  host  sim- 
ulation processor  and  Is  the  real-time  simulation  of  the  real  world, 
the  aircraft  and  the  avionics  sensor  suite  and  weapon.  The  simulation 
software  consists  of  a simulation  executive  and  scenario  generator;  and 
a set  of  simulation  models. 

The  simulation  software  operates  with  a major  cycle  (conpu- 
tatlonal  cycle)  rate  of  32  times  per  second.  The  SSDF/URT  PDF  11 
processor  generates  an  Interrupt  to  the  DEC-10  32  times  per  second  to 
start  each  computation  cycle.  At  the  start  of  each  computational 
cycle,  the  simulation  reads  all  Inputs  from  the  PDP  11  and  then  gen- 
erates an  Interrupt  to  the  PDP  11.  The  simulation  then  performs  Its 
calculations  and  outputs  Its  data  to  the  DMA  area. 
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5.8 


Picture  System 


The  picture  system  shown  In  Figure  32  consists  of  a simula- 
tion software  controlled  ground  display  graphics  generator  and  projec- 
tor system.  The  graphics  generated  display  of  the  ground  a$  seen  by 
the  "pilot"  In  the  simulated  cockpit.  Is  projected  on  a motion  picture 
screen  In  front  of  the  cockpit. 

An  Evans  and  Sutherland  graphics  system  generates  an  Ideal- 
ized pattern  which  represents  ground  terrain,  targets, ^mfiway,  Me. 

The  Evans  and  Sutherland  Is  controlled  by  the  DEC-10  simulation  soft- 
ware via  the  POP  11  processor.  The  graphics  are  generated  on  a stroke, 
CRT  display  and  monitored  by  a closed  circuit  television  camera.  The  •' 
TV  Image  Is  transmitted  to  the  Advent  projection  subsystem. 
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FIGURE  32.  FUNCTIONAL  COflFIGURATIOIl  - PICTURE  SYSTEM 


The  modular,  well  defined  structure  and  interfaces  of  the 
har(Kfare  and  software  elements  In  the  DAIS  System  Architecture  greatly 
facilitates  the  Integration  and  test.  A step-by-step  building  block 
approach  was  taken  to  Int:  grate  and  test  these  elements,  for  both  the 
DAIS  core  elements,  as  well  as  the  support  facility  har^are  and  soft- 
ware which  supported  the  real  time  demonstrations.  Figure  33.  Initially, 
standalone  tests  were  performed  on  Individual  elements,  and  then  these 
elements  were  Incrementally  Integrated  and  tested  until  the  full  system 
was  completed  for  the  Initial  demonstration.  The  following  section  high- 
lights several  of  the  key  techniques  which  contributed  to  the  successful 
and  rapid  Integration  and  test  activities. 

6.1  Standalone  Tests  . , 


6.1.1 


Core  Element  Hardware 


As  each  core  element  subsystem  was  received  from  the  con- 
tractor, standalone  acceptance  tests  were  performed,  first  using  the 
contractor  supplied  test  support  equipment  and  software.  These  tests 
were  then  augmented  with  AFAL  and  SITC  tests.  These  tests  were 
developed  to  verify  all  the  electrical  and  functional  Interfaces  of 
each  subsystem.  In  several  cases,  the  contractor  supplied  tests  were 
not  very  comprehensive,  and  the  test  support  equipment  did  not  allow 
complete  dynamic  testing  of  all  the  functional  Interfaces.  As  a 
result,  specifically  for  the  multiplex  equipment,  complete  acceptance 
testing  of  these  core  elements  was  not  completed  until  the  subsystem 
was  Integrated  and  tested  with  other  system  elements  as  discussed  In 
the  hardware  Integration  and  test  section  below. 


6.1.2 


Executive  Software  Testinc 


The  DAIS  Executive  was  also  tested  In  an  Incremental 
fashion.  A set  of  application  tasks,  called  “stubs",  were  developed 
which  would  exercise  the  various  Executive  functions:  pure  executive 
service  functions,  synchronous  bus  control,  asynchronous  bus  contrcl, 
timing  functions,  and  for,  both  the  remote  and  master  operations,  • 
First,  the  local  executive  was  tested  using  the  SDVS  statement  level 
simulation  on  the  DEC-10.  Following  that,  the  local  executive,  was 
Integrated  with  master  executive  and  tested  as  a one  processor 
(master)  configuration,  again  Incrementally  with  added  “stubs"  to 
test  the  various  functions.  This  testing  was  performed  on  the  proces- 
sor/BCIU  using  support  hardware  as  the  “terminals"  to  receive  or 
transmit  bus  messages.  After  the  single  processor  tests  were  suc- 
cessfully completed,  key  "stubs"  were  repartitioned  to  .the  second 
processor  to  test  the  remote  operation  of  the  local  executive,  again 
Incrementally,  until  all  the  functions  were  successfully  tested.  ,The 
next  phase  was  partitioning  of  additional  "stubs"  to  a third  proces- 
sor and  repeating  the  set  of  tests  to  verify  a three  processor 
operation.  Numerous  problems  were  uncovered  In  the  Executive, 

PALEFAC,  processor,  and  BCIU.  After  these  problems  were  corrected, 
all  the  features  performed  as  stated  In  the  Executive  Specification 
as  summarized  below. 
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1.  Synchronous  bus  traffic  between  master  proces-  . 

sor,  remote  processors,  and  the  URT  (simula^d  ‘ ,, 

RT)  operated  as  required. 

2.  Asynchronous  bus  traffic  operated. as  requii^ed.. 

This  includes  TRIGGERS  from  master  and  rembte'  ' 

processors,  asynchronous  WRITES,  BROADCASTS  with 
all  the  possible  combinations  of  procqssqrjj  and 
RTs. 

3.  Event  handling,  both  latched  and  unlatched,  ' 
operated  as  required.  This  includes  interpro-  , 

,cessor  and  intraprocessor  signals,  vfaits,  . / 

compool  update  events,' dispatching,  task 
priorities,  and  all  their  interrelationships. 

4.  Cancels  and  terminates  operated  as  required  for  * 
both  interprocessor  and  intraprocessor  requests. 

5.  Synchronous  reads  and  writes  operated  as 
required.  This  includes  resolving  conflicts 
when  a real  or  write  request  occured  during 
the  update  minor  cycle  for  that  conpool. 

6.  The  real-time  read,  and  wait  on  time  performed 
as  required  in  both  the  master  and  remote 
processors. 

A limited  amount  of  error  testing  was  done  in  a separate 
test.  This  consisted  entirely  of  forcing  'busy*  conditions  in  the 
remote  processors,  then  checking  to  be  sure  the  error  processing 
handled  the  condition  properly  and  the  data  was  received  as  required. 
All  possible  combinations  of  synchronous  and  asynchronous  bus  traffic, 
involving  remote  processors,  were  tested.  The  executive  was  able  to 
handle  tee  retries  successfully  in  all  cases. 

6.1.3  Application  Software  Unit  Test 

Unit  Test  of  the  Application  Software  was  performed  on  the 
Host  Computer  System.  At  this  level  of  testing,  the  main  concern  was 
whether  or  not  the  logical  operation  of  a single  task  is  correct.  A 
version  of  the  DAIS  Executive  was  hosted  on  the  Host  Computer  System, 
and  by  compiling  the  task  for  the  Host  Computer  Code  Generator, 
running  the  task  under  test  through  PALEFAC,  and  then  linking  the  task 
with  the  Executive,  a test  set  was  created.  This  set  was  executed  on 
the  Host  Computer  System.  The  user  can  specify  inputs,  cycle  the  task 
with  the  executive,  and  record  the  outputs.  The  user  can  also  define 
lists  of  Inputs,  perform  several  cycles  of  execution,  and  record  the 
list  of  outputs.  As  a result,  once  internal  unit  testing  has  been 
completed,  an  effective  automatic  or  regressive  testing  capability 
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Hardware  Integration  and  Test 
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Incremental  Integration  and  testing  of  each  subsystem  was 
performed,  as  they  became  available,  until  the  system  was  fully  In- 
tegrated and  tested.  The  key  to  the  successful  Integration  and  test 
was  the  development  of  extensive  test  software.  Two  major  test  soft- 
ware programs  were  developed:  System  Diagnostics  Software  and  Command 
Generation  Software.  The  System  Diagnostics  was  developed  In  a struc- 
tured and  modular  fashion  so  additional  tests  could  be  readily  added. 
Several  of  the  key  features  of  these  software  test  programs  were: 

• Testing  of  all  functional  areas  of  the 
core  elements  under  test. 

a Testing  of  functional  areas  with  extensive 
data  patterns  with  error  checking  under 
test  software  control.  Many  failure  modes 
were  bit  pattern  sensitive  and/or  Intermit- 
tent requiring  large  number  of  data  patterns 
at  the  system  operating  speed  in  order  to 
detect  and  Isolate. 

a Segmenting  test  software  to  functional  areas 
of  the  hardware  under  test.  This  facilitated 
problem  Isolation  by  allowing  the  test  oper- 
ator the  option  of  running  test  software  on 
the  falling  segment  only. 

a Providing  stop  on  error  and  loop  on  section, 
subsection,  and  falling  data  pattern.  This 
facilitated  problem  Isolation  and  provides 
conditions  under  which  a problem  (even  Inter- 
mittent), could  be  "scoped"  or  traced  with  a 
logic  analyzer. 

a Generating  data  patterns  at  execution  rates  at 
least  conparable  to  the  normal  operation  rate 
for  the  equipment  under  test.  Many  failure 
modes  were  Induced  only  at  or  near  maximum 
data  rates  because  of  noise,  signal  line 
"ringing"  or  "cross  talk"  and  other  high  speed 
phenomena. 

a Capability  to  sequence  through  all  phases  of 
the  test  repetitively  (looping)  with  error 
checking.  Capability  allowed  equipment  testing 
for  thermal,  noise,  and  other  Intermittent 
errors,  and  provided  a high  degree  of  confi- 
dence when  equipment  operated  successfully  for 
extended  periods  of  time. 
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• Support  system  verification  prior  to  loading 
and  running  mission  software,  and  supporting 
problem  detection  and  Isolation  during  mis- 
sion software  checkout  and  predemonstration 
phases.  System  Integrity  was  established 
before  loading  mission  software  so  mission 
software  debugging  would  not  be  plagued  with 
hardware  problems. 

a Structured  and  modular  test  software  to 

facilitate  development  in  stages  and  to  allow 
Inclusion  of  test  software  from  various 
sources. 


3 


Appllcdtion  Software  - Integration  and  Test 


Once  interface  compatibility  testing  was  performed  upon  a 
set  of  tasks  that  formed  an  application  software  subsystem  (such  as 
Navigation),  the  next  step  was  to  compile  those  same  tasks  for  the 
I^IS  processor,  generate  a load  for  the  system,  and  test  that  load  - 
executing  in  real  time  interfacing  with  the  sensor  devices  and  Con- 
trols and  Displays  equipments  over  the  multiplex  bus.  As  each  sub-, 
system  was  checked  out,  the  next  subsystem  was  added  to  ^e  test  set 
as  a unit  and  another  set  of  tests  for  the  added  subsystem  and  the  ' 
added  sensors  was  run.  The  result  was  that  system  integration  was 
completed  when  the  last  subsystem  was  integrated  and  tested.  The 
Integration  process  went  extremely  smoothly,  and  the  major  problems', 
were  in  the  areas  of  the  interface  definition  with  the  simulated  ^ 
sensors,  the  interface  definition  with  the  Controls  and  Displays' 
equipment,  problems  found  in  the  Compiler  Code  generator ‘ for  the  DAIS 
processors,  and  with  the  instruction  execution  on  the  DAIS  processor. 
None  of  these  problems  involved  functional  redesign  of  the  Application 
Software,  and  thus  illustrated  the  ease  with  which  system  integration 
and  testing  can  be  done  with  this  software  development  approach,  . 


7.0 


REPRESENTATIVE  APPLICATION 


7.1  Mission  Demonstration 

The  overall  DAIS  objectives  are  to  (1)  reduce  unnecessary 
development  proliferation,  (2)  improve  operational  efficiency  Including 
availability/maintainability,  and  (3)  improve  flexibility  to  changes. 
These  objectives  must  be  achieved  without  sacrificing  the  mission 
avionic  functional  capability  attainable  with  conventionally  configured 
complements  of  sensor  and  weapon  subsystems.  The  satisfaction  of  these 
objectives  and  the  requirement  for  acceptable  system  functional  capa- 
bility has  been  illustrated  by  successfully  operating  DAIS  under  simu- 
lated mission  conditions.  Specifically,  the  mission  demonstration  has 
illustrated:  (1)  the  pilot  interface  with  Controls  and  Displays  (C4D), 
(2)  the  operation  of  the  processors,  mission  software  and  multiplex 
system  under  realistic  workload  conditions,  and  (3)  the  ability  of 
the  system  to  perform  weapon  delivery  and  navigation  functions. 

The  DAIS  demonstrations  were  performed  in  the  Integrated 
Test  Bed  facility.  The  purpose  of  this  facility  is  to  test  DAIS 
mission  software  and  core  element  hardware  under  real-time  conditions. 
The  facility  provides  a real  time  simulation  of  a military  aircraft 
performing  an  operational  mission.  The  simulation  generates  the 
interface  signals  so  that  the  DAIS  equipment  and  mission  software  is 
subjected  to  a data  signal  environment  which  Is  nearly  Identical  to 
actual  flight. 

Simulation  software  was  developed  to  provide  real  time 
simulation  of  military  aircraft  in  an  operational  environment  including 
the  aircraft  dynamics,  the  aircraft  sensors  and  weapon  targets.  The 
simulation  is  driven  from  the  cockpit  by  an  operator  acting  as  a 
“pilot".  This  simulated  cockpit  is  equipped  with  the  DAIS  controls 
and  displays  so  that  the  various  modes  of  a mission  may  be  “flown" 
by  a “pilot"  with  an  out-the-window  background  scene. 

The  Mission  a demonstration  was  successfully  performed  during 
September  1978,  to  demonstrate  the  DAIS  system.  This  demonstration  is 
the  first  of  the  four  scheduled  Close  Air  Support  (CAS)  demonstrations. 
This  Initial  demonstration  Included  functional  capabilities  such  as: 
Inertial/Baro-Damped  Navigation;  Command  Navigation,  TACAN  and  ILS 
Steering;  NK82  Weapon  Delivery  (with  weapon  scoring);  Stores  Manage- 
ment; and  preflight,  takeoff/climb,  cruise  and  approach/land  check- 
lists. 


The  simulation  was  flown  from  the  DAIS  cockpit  using  active 
DAIS  Controls/Displays  and  simulation  models  which  reside  on  the  DEC-10, 
as  shown  In  Figure  23.  No  real  sensors  were  used  In  the  demonstration. 
The  avionic  system  consists  of  a two  processor  DAIS  configuration 
at  shown  in  Figure  34  and  Table  11.  All  communication  between  the  DAIS 
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PROCESSOR  #1  COCKPIT 


FIGURE  34.  MISSION  a CONFIGURATION 


TABLE  n.  MISSION  o CONFIGURATION 


Weather: 

Target: 

Weapons: 

Threats: 

Simulated 
Sensors : 


Core  Element 
(Hardware): 


Support  Facility: 


Functions: 


Night  - Clear  (VFR) 
Fixed  Ground  Target 
MK-82  LDGP  Bombs 
None 


INS(SKN2416) 

Laser  Ranger 
Air  Data  Sensors 
Radar  Altimeter  (APN-141) 
ILS  (ARN-58A) 

TACAN  (ARN-118) 


DAIS  Processors  (2):  Master  & Remote  #1 

BCIUs  (2) 

RTs  (2) 

Controls  and  Displays 
RT  (1)  C&D  Mass  Memory 

VSD  SCU 

HSD  HUD 

MPD-1  PCP 

MPO-2  MPDG  (1) 

IMFK  DSMU 

DEK  AP 

MMP 

ITB  Functional  Diagram  as  shown  In 
Figure  24. 

Navigation  - Inertlal/Baro-Damped 

Steering  - Command  NAV 
TACAN 
ILS 

Navigation  Update  - Flyover 

HUD/Laser  Ranger 
FLIR/Laser  Ranger 

Acquis Itlon/Cueing  - Pllot/HUD 

Pllot/FLIR 

Target  or  (OAP)  Fix  - HUD/Laser  Ranger 

FLIR/Laser  Ranger 
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TABLE  11.  MISSION  a CONFIGURATION  (CON'T) 


r ' 


Weapon  Delivery  - CCIP/Auto 
CCIP/Manual 

Stores  Management' 
Communications  - UHF 
rhprkUct 


• • I .ir 

. ■ r-  1 
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processors/Bus  Control  Interface  Unit,  the  DAIS  cockpit  and  the  simu- 
lation models  was  accomplished  over  a dual  redundant  MIL-STD-1553A 
multiplex  bus  using  DAIS/15S3A  system  protocol.  A DAIS  remote 
terminal  was  used  to  Interface  the  DAIS  cockpit  electronics  to  the 
dual  redundant  1S53A  multiplex  bus.  The  subsequent  Missions  will 
employ  additional  sensors,  such  as  Pave  Penny  and  VATS/Pave  Tack, 
to  demonstrate  additional  navigation  updates,  target  acquisition/ 
queueing,  and  weapon  delivery  functions.  Also,  additional  features 
to  demonstrate  system  startup/restart,  recovery,  backup,  and  reconfig- 
uration will  be  performed  In  these  subsequent  Missions. 


7.2 


Application  Software  Partitioning 

The  Application  Software  required  to  implement  the  Mission  a 
requirements  was  initially  broken  into  the  following  major  areas:  Navi- 
gation. Steering,  Weapon  Delivery,  Stores  Management,  Display  Control, 
Display  Driving,  System  Control,  and  Pilot  Interface  as  shown  in  Figure 
34.  The  performance  requirements  for  each  area  were  defined,  based 
upon  the  System  Segment  Specification  for  the  Mission  a configuration, 
and,  then,  the  initial  system  design  began.  The  data  interfaces  to 
and  from  the  external  devices  were  first  defined  as  Compool  Bl(;hiks.  • 

Figure  35  provides  an  example  of  the  Navigation  subsystem  structure  i 

and  data  flow.  Then,  the  initial  definition  of  the  individual  tasks  w^s 
begun.  This  task  layout  was  performed  by  defining  the  individual  func- 
tions required,  defining  under  what  conditions  and  in  what  order  these 
functions  should  occur,  and  then  grouping  those  functions  which  were 
logically  related  and  occurred  under  the  same  conditions  together  as 
Tasks.  Refer  to  Figures  36,  37,  and  38  for  examples  of  Navigation 
Subsystem.  Once  data  layout  was  completed,  the  design  and  development 
of  the  individual  tasks  began,  as  did  the  design  of  the  system  control 
for  each  subsystem.  The  design  involved  defining  the  modes  of  operation 
of  each  subsystem,  how  the  controlling  task  would  control  the  subtasks 
in  order  to  implement  these  modes,  and  how  the  subsystem  would  report  ‘ _ 
current  operating  modes  as  well  as  unusual  conditions  as  outputs. 

As  the  design  of  the  system  evolved,  it  became  apparent  that- 
the  system  consisted  of  a synchronous  portion  which  must  execute  contin- 
uously (within  a given  mode  of  operation)  and  an  asynchronous  portion 
that  executes  upon  the  change  of  a mode  (Navigation  Controller  for  , 
exairiple),  or  upon  the  performance  of  some  operation  (passing  over  the 
next  waypoint  in  the  flight  plan  for  example),  or  upoii  pilot  action 
(performing  a position  update  for  example).  From  the  beginning  of  the 
system  design  it  was  important  to  establish  time  of  execution  and  size 
requirements  for  each  task,  as  well  as  to  keep  a synchronous  task 
execution  and  synchronous  bus  message  transfer  plan  (Figure  38).  The 
plan  defines  how  each  of  the  pieces  of  the  synchronous  poKion  of  the' 
system  operates,  as  well  as  how  it  executes  with  respect  to  the  other' 
pieces.  Once  the  definition  of  the  tasks  and  the  data  interfaces 
were  completed,  the  last  major  task  of  system  design,  the  system  parti- 
tioning, started.  This  step  consists  of  determining  which  tasks  wiTl 
execute  upon  which  processors  in  the  system.  There  are  maqy  factors  which 
go  into  making  this  decision.  These  factors  are;  desire  to  keep  subsys- 
tems together  as  a unit  due  to  their  generally  high  transfer  of  data  be- 
tween their  individual  tasks,  desire  to  keep  system  control  functions  in 
the  master  processor  to  facilitate  its  comnuni cations  with  all  of  the' 
subsystems,  desire  to  keep  pilot  interface  in  the  master  processor  to' 
facilitate  its  communication  with  the  pilot  keyboard,  and  the  desire- 
to  balance  high  CPU  throughput  tasks  against  high  memory  size  tasks  id 
order  to  avoid  having  one  processor  CPU  time  bound,  and  another  memory 
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FIGURE  35.  NAVIGATION  SUBSYSTEM  STRUCTURE  AND  DATA  FLOW 


FIGURE  36.  NAVIGATION  SUBSYSTEM  ARCHITECTURE 


(fpiTfvT 

AIR  DATA 

(-1) 

INPUT  (EQUIP) 

AIR  DATA 

(PRIV) 

COMPUTER  (SPEC) 

INS  ALT 

(-2) 

OUTPUT  (EQUIP) 

INS  POSITION 

(PRIV) 

UPDATE  (EQUIP) 

INS  DATA 

(-3) 

INPUT  (EQUIP) 

INS  CONTROL 

(-4) 

(EQUIP) 

INS  ALIGN 

(-5) 

CONTROL  (CNTRL) 
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NAV  PROCESSING 
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HIND  PROCESSING 
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FIGURE  37.  NAV  SUBSYSTEM  RELATION  PRIORIH 
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space  bound.  This  system  layout  design  was  done.  Initially,  and  then, 
repeated  over  many  times  In  order  to  find  an  efficient  partitioning. 

The  PALEFAC  tool  was  extremely  useful  In  the  Iterative  process  since  It 
accepts  the  user's  description  of  the  system  partitioning  as  an  Input, 
and  generates  the  system  loading  as  an  output.  Part  of  this  loading 
Information  was  the  declaration  of  what  transactions  occur  between 
processors,  as  well  as  the  memory  size  of  each  processor.  As  a result, 
the  user  begins  to  determine  where  bottlenecks  In  the  system  exist,  and 
make  system  configuration  changes  to  eliminate  these  problems.  Once  a 
stable  system  configuration  has  been  reached,  PALEFAC  was  not  required 
unless  changes  In  that  configuration  occur. 

The  Integration  and  test  of  the  application  software  subsys- 
tem was  performed  In  9 steps  as  shown  In  Figure  39.  Incrementally,  a 
subsystem  was  added  and  tested  with  the  appropriate  simulated  sensor  or 
control  and  display  elements.  During  the  Initial  Integration  process, 
three  DAIS  processors' were  used,  partitioning  the  application  software 
as  shown  In  Figure  39  across  all  three  machines.  This  was  performed  so 
the  subsystems  could  be  verified  prior  to  performing  throughput  measure- 
ments on  each  application  task.  Initially  the  throughput  was  tetermlned 
to  be  too  high  for  a two  processor  configuration.  However,  after  further 
examination,  several  subsystems  were  executing  at  a rate  higher  than 
required,  specifically  subsystems  driving  the  displays.  The  Iteration 
rates  of  these  subsystems  were  reduced  and  the  application  software 
subsystems  were  all  Integrated  Into  the  two  processor  configuration,  as 
shown  in  the  final  step  In  Figure  39. 

This  Integration  sequence  demonstrated  the  powerful  capa- 
bilities Inherent  In  the  DAIS  architecture  and  tools: 

1.  Capability  to  readily  repartition  the 
system. 

2.  Capability  of  the  system  to  continue 
operation  even  if  overload  of  the  proces- 
sor throughput  occurred,  with  only  the 
lower  priority  tasks  not  executing  as 
often  as  Initially  desired. 


If  MSS 


The  DAIS  Demonstration  Plan/Procedures  provided  an  orderly 
set  of  Instructions  for  the  test  managers  and  participants  to  plan  and 
to  conduct  the  execution  of  the  demonstration  tests.  They  consist  of: 
(1)  scheduling  of  resources,  (2)  test  preparation,  (3)  test  execution, 
including  data  collection  and  real  time  analysis,  and  (4)  post-run 
analysis,  reporting,  and  record  keeping. 

The  scheduling  requirements  for  use  of  the  DAIS  equipment 
and  facility  for  the  demonstration  tests  were  set  forth  to  Insure 
availability  of  equipment  and  area  for  specified  time  periods.  Addi- 
tionally, It  Included  assignments  of  personnel  as  test  conductor, 
cockpit  operator  (pilot),  and  other  supporting  roles. 

The  test  preparation  Included:  (1)  setting  up  of  the  DAIS 
and  the  Support  Facility  equipment  for  the  specific  mission  configur- 
ation, (2)  complete  checkout  of  the  system,  (3)  a full-up  all- 
personnel dry  run  or  final  rehearsal. 

The  demonstration  consisted  primarily  of  the  pilot  executing 
the  cockpit  operations  required  in  an  actual  mission  flight.  A pre- 
run briefing  was  given  to  describe  the  objectives,  mission  phases, 

DAIS  configuration,  test  operator  functions,  and  pilot  actions  during 
the  test.  The  briefing  was  a review  of  the  demonstration  plan  with 
particular  emphasis  on  the  mission  to  be  run.  During  the  test  execu- 
tion a narrative  was  provided  to  the  observers  pointing  our  significant 
activities. 

Data  was  recorded  during  test  execution  for  subsequent  post 
processing  and  analysis.  A formal  test  report  was  generated. 

7. 3. 1 Pre-Demonstration  Procedures 

Prior  to  Initiation  of  the  Mission  demonstration  sequence, 

ITB  readiness  was  verified.  The  various  core  elements  and  support 
system  elements  were  tested  and  their  performance  verified. 

The  ITB  system  was  enabled  by  the  following  procedures: 

• Apply  power  to  SSDF  and  PMC  PDP  11 /40s, 

E&S  PDP  11/50,  miscellaneous  support 
equipment 

t Perform  Mux  (BCIU  & RT),  Processor, 

Cockpit  Self-Tests. 

• Load  appropriate  POP  11/40  and  OEC-10 
support  software. 
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• Select  and  Initialize  Simulation  Models 
e Initialize  SSDF»  PMC,  E&S  processors 

• Load  Mission  Software  In  OAIS  Processor 

After  all  support  equipment  was  activated,  the  avionics 
processors  and  multiplex  system  were  activated.  The  normal  pilot 
sequence  for  these  operations  Is: 

e DAIS  Bus  Power  Switches  ON 

e Processor  Power  Switches  ON 

e Check  Processor  Power  Lamps  Lit  Green 

e Check  IMFK 

After  the  system  was  determined  to  be  operable,  the  pilot  was 
notified  on  the  IMFK:  "System  Ready". 

7.3.2  Mission  a Demonstration  Procedures 

The  pilot  sequences  through  the  mission  operations,  using 
the  Integrated  DAIS  Controls  and  Displays  (C40)  to  display  Information 
from  mission  software  about  the  mission  and  avionics  functions,  and  to 
control  operations  to  be  performed  by  the  software.  Master  amdes  set 
the  display  devices  In  certain  nominal  formats,  which  can  be  overridden 
by  the  pilot  to  cause  alternate  modes  or  operations. 

The  demonstration  scenario  for  the  mission  Is  outlined  In 
Table  12  and  shown  In  Figure  40.  Discussion  of  the  various  flight 
phases  and  operations  Is  presented  below. 

7.3.2.1  Prefllght 

The  system  Is  Iniliallzed  to  a NULL  master  mode  after  all 
AN/AYK-15  processors  and  MPDOs  are  loaded,  waiting  for  pilot  selection 
of  a master  mode.  The  pilot  Is  then  prompted  on  the  IMFK  to  select 
the  Prefllght  Master  Mode  (PREFLT). 

This  master  mode  can  be  selected  after  Initial  program  load 
until  the  weight  Is  off  the  gear,  provided  no  master  mode  other  than 
Takeoff/Cl Irt)  has  been  selected.  (After  weight  Is  off  the  gear,  the 
switch  output  Is  Ignored  by  mission  software  until  weight  Is  on  the 
gear).  PREFLT  CHKLIST  on  the  IMFK  can  be  selected  using  the  Library 
specialist  function  without  selection  of  the  Prefllght  on  the  master 
mode  panel.  The  checklist  permits  verification  and/or  modification  of 
mission  data  and  verification  of  take-off  readiness. 


-135- 


TABLE  12.  MlSSIOtt  SCEIIARIO 


FIGURE  40.  DEMONSTRATION  SCENARIO 


Tailored  mode  preflight  operations  are  displayed  on  the  IMFK 
for  pilot  checklist  responses.  Selected  formats  are  displayed  and 
exercised  by  mission  software  for  the  HSD,  VSD,  MPD-1,  and  MPD-2,  so 
that  the  pilot  can  adjust  brightness,  contrast;  and  check  display 
symbology,  mission  software,  equipment  performance,  etc.  The  DAIS 
system  status  Is  displayed  on  MPD-2.  The  software  Issues  commands  to 
RTs  automatically  to  turn  on  equipment  and  select  modes. 

Normally,  the  avionics  system  remains  1n  the  prefllght  state 
until  the  system  has  been  set  up  for  a mission  configuration.  The 
pilot  can  select  T.O./CLIMB  any  time  after  completing  step  1 of  page  1 
of  the  checklist.  If  the  pilot  falls  to  select  T.O./CLIMB  and  begins 
TAKEOFF  while  In  PREFLIGHT,  the  system  shall  automatically  advance  to 
T.O./CLIMB  when  weight  Is  off  the  gear. 

7.3.2.2  Takeoff/CLIMB 

The  pilot  may  select  T.O./CLIMB  on  the  Master  Mode  Panel 
(MMP)  only  after  the  avionics  systems  turn  on  (preflight,  page  1, 
step  1)  has  been  accomplished  during  the  preflight  master  mode. 
Omitting  steps  In  preflight  may  degrade  system  performance.  If  the 
pilot  falls  to  select  T.O./CLIMB  and  takes  off  in  PREFLT,  the  mission 
software  shall  advance  to  the  T.O./CLIMB  master  mode  when  weight  off 
the  gear  Is  detected. 

The  Takeoff  operational  sequence  begins  by  the  depression 
of  the  T.O./CLIMB  master  mode  and  switches  to  the  CLIMB  operational 
sequence  when  weight  Is  detected  off  the  gear.  The  preflight  OPS 
cannot  be  activated  when  weight  Is  off  the  gear.  The  MPD-2  displays 
a takeoff  checklist,  followed  by  a climb  checklist.  The  pilot  may 
input  new  UHF  or  TACAN  frequencies  during  the  T.O./CLIMB  mode. 

7.3.2. 3 Cruise 

The  cruise  mode  is  initiated  by  depressing  the  CRUISE  master 
mode  key.  This  results  in  a standard  display  of  data  on  the  HUD,  VSD, 
HSD,  and  MPD-2.  The  IMFK  presents  tailored  functions  likely  to  be 
required  without  going  through  various  levels  of  indenture  to  access 
these  functions. 

Navigation  and  steering  functions  were  exercised  during  the 
cruise  flight  phases  of  the  mission.  The  modes  selected  for  the  mis- 
sion are  shown  In  Table  12. 

Primary  navigation  was  baro-damped  INS. 

Navigation  updates  were  Initiated  by  first  selecting  the  Nav 
Specialist  Function  and,  subsequently,  Nav  Update.  For  Mission  a, 
either  FLYOVER  or  FLIR/LASER  can  then  be  selected.  For  FLIR/LASER 
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updating*  the  Aiming  Reticle  (AR)  Is  positioned  over  the  update  point 
on  the  HUO/FLIR  display.*  In  both  cases,  the  Sensor  Control  Unit  (SCU) 
Is  used  to  designate  the  update  point.  Selection  of  UPDATE  causes 
longitude  and  latitude  to  be  updated  to  values  computed  by  the  selected 
update  mode. 

The  default  steering  mode  for  the  mission  was  Command  Nav, 
which  generates  steering  commands  along  a great  circle  route  from 
present  position  to  the  next  route  point  In  the  flight  plan*  The  pilot 
may  select  a new  waypoint  from  those  In  the  flight  plan  by  Activating 
the  FLY  TO  coamand  on  the  CRUISE  IMFK  display  and  entering  a new  way« 
point  Identification  number.  New  waypoints  can  be  Introduced  by 
selecting  the  Nav  Specialist  Function  on  the  IMFK  and  by  selecting  Nav 
Data  Entry  on  the  subsequent  IMFK  display. 

TACAN  steering  was  selected  In  all  missions  by  the  TCN  key  In 
the  Nav  Specialist  Function  display.  The  IMFK  responds  with  the  NAV 
TACAN  sensor  mode  control  display.  A channel  change  can  be  Initiated 
by  selection  of  TCN  CHNG. 

7. 3. 2. 4 Weapon  Delivery 

Several  weapon  delivery  techniques  were  exercised  In  the 
demonstration  mission.  Table  11  lists  the  capabilities  available  for 
the  mission.  Table  13  notes  the  weapon  load  options  exercised  In  the 
mission.  The  weapon  delivery  options  are  discussed  below. 


a.  Continuously  Computed  Impact  Point/Automatic  Release 


[caijrma; 


In  this  mode,  the  weapon  delivery  computations  are  based 
upon  relative  target  data  from  a currently  ranging  sensor  subsystem. 
Steering  data  Is  computed  and  displayed  guide  the  pilot  to  a release 
condition.  Release  Is  automatic  with  pilot  concurrence.  In  the  event 
of  loss  of  track  during  this  mode,  the  system  will  use  alternate  methods 
to  compute  release  conditions.  In  this  mode,  an  offset  aim  point  may  be 
used  with  pilot  Input  of  the  offset  range  and  bearing  to  the  target 
from  the  aim  point. 

This  mode  Is  selected  by  depressing  the  CCIP/AUTO  master 
mode  panel  switch.'  It  Is  used  to  control  the  avionics  operations  when 
performing  a computed  automatic  release  air-to-ground  bomb  delivery 
with  visual  target  acquisition/tracking  or  guided  air-to-ground  weapons. 
Selection  of  a new  Urget  (redesignation)  or  a new  weapon  for  delivery 
causes  the  weapon  delivery  computations  to  be  restarted  based  on  the 
newly  selected  data . - ' 


*The  HUD/FLIR  display  will  be  represented  by  the  E4S, display.*. : 
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Visual  offset  bombing  is  performed  using  this  master  mode  and 
insertion  of  offset  aiming  point  (OAP)  data. 

Selection  of  a weapon  program  provides  a "quick  change”  page 
on  the  INFK  for  the  weapon  selected.  This  page  permits  the  pilot  to 
change  release  parameters  and  then  return  to  the  tailored  page. 

After  selecting  a weapon  delivery  master  mode,  the  bomb  fall 
line  (BFL)  appears  on  the  HUD.  The  BFL  will  pass  through  the  flight 
path  marker  (FPM).  The  aiming  reticle  (AR)  will  appear  stowed  within 
the  FPM,  and  the  pull-up  anticipation  cue  will  appear  3.5°  below  the 
FPM  on  the  BFL.  CCIP/AUTO  can  be  selected  to  bomb  any  visually  acquired 
target.  However,  if  the  barometric  ranging  mode  comes  into  priority, 
the  altitude  and  mean  sea  level  pressure  (MSLP)  stored  or  a waypoint, 
which  could  have  been  selected  under  the  FLY  TO  function  during  the 
cruise  master  mode,  are  used  for  slant  range  computations.  If  these 
values  are  not  correct  for  the  target  being  attacked,  the  desired 
accuracy  will  not  be  obtained. 

When  this  master  mode  is  selected,  the  HUD  switch  lamp  is  lit 
on  the  sensor  control  unit  (SCU)  which  indicates  the  SCU  controls  the 
position  of  the  HUD  aiming  reticle.  The  SCU  can  be  used  to  move  the 
aiming  reticle  in  any  direction.  The  BFL  moves  with  the  aiming  reticle 
until  designation.  If  the  slewing  is  terminated,  without  designation, 
the  aiming  reticle  becomes  ground  stabilized  just  as  though  target  des- 
ignation had  been  accomplished.  Once  the  pilot  designates  the  target 
with  the  designation  button  on  the  SCU,  the  aiming  reticle  is  stabilized 
to  remain  on  the  designated  point  on  the  ground.  Upon  designation,  the 
flight  director  is  removed  and  the  BFL  will  no  longer  intersect  the 
aiming  reticle,  but  will  be  halfWay  between  the  aiming  reticle  and  the 
FPM,  indicating  the  required  lateral  steering.  As  the  aircraft  advances 
toward  target,  the  aiming  reticle  (and  the  target)  may  disappear  from 
the  pilot's  field-of-view.  Depression  of  the  designate  button  a second 
time  will  undesignate  the  target  and  restow  the  aiming  reticle  and  BFL 
on  the  FPM.  Once  the  target  is  within  range,  the  solution  cues  appear 
on  the  HUD,  and  weapon  delivery  may  proceed. 

If  delivery  of  a weapon  selected  in  this  master  mode  Is  not 
completed  and  transition  to  another  weapon  delivery  master  mode  occurs 
in  which  this  weapon  is  a valid  choice,  the  option  remains  active.  If 
a non-weapon  delivery  master  mode  is  selected,  all  weapons  are  auto- 
matically dearmed.  The  weapon  options  used  in  the  mission  are  shown 
in  Table  13. 

Command  steering  from  the  previous  master  mode  reamlns  active 
on  the  VSO  until  'target  designation,  at  which  time  attack  steering  Is  - 
engaged.  Attack  steering  Is  target  referenced  for  both  the  VSD  and  HUD 
and  steers  to  a release  point. 
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b.  Continuously  Computed  Impact  Point/Manual  Release  fCCIP/ 

Manual) 

In  this  mode,  the  AR  on  the  HUD  will  be  located  at  the 
current  bomb  or  gunnery  Impact  point.  The  pilot  then  flies  the  air- 
craft to  bring  the  AR  Into  coincidence  with  the  target.  There  will  be 
two  submodes  to  the  CCIP/manual  mode  depending  upon  pilot  selection  of 
either  bombs. 

ITils  mode  Is  selected  by  depressing  the  CCIP/Nanual  master 
mode  panel  switch.  It  Is  primarily  to  control  the  avionics  operations 
when  performing  an  air-to-ground  gunnery  or  rocket  attack  with  visual 
target  acquisition/tracking  and  manual  release.  It  Is  also  used  as  a 
backup  mode  to  release  gravity  type  weapons.  Selection  of  a new  target 
or  a new  weapon  for  delivery  causes  the  weapon  delivery  computations 
to  be  restarted  based  on  the  newly  selected  data. 

If  delivery  of  a weapon  selected  In  this  master  mode  Is  not 
completed  and  transition  to  another  weapon  delivery  master  mode  occurs 
In  which  this  weapon  Is  a valid  choice,  the  option  remains  active.  If 
a non-weapon  delivery  master  mode  Is  selected,  all  weapons  are  auto- 
matically dearmed. 

Steering  from  the  previous  master  mode  remains  active  until 
target  designation,  at  which  time,  attack  steering  Is  engaged.  Attack 
steering  is  target  referenced -and  steers  to  a release  point. 

7.3.2. 5 Approach  and  Land 

Approach  and  Land  can  be  either  non-precision  or  precision, 
the  latter  using  ILS.  The  corresponding  master  modes  are  described 
below. 

a.  Approach  and  Land  Master  Mode 

This  master  mode  Is  entered  by  pilot  selection  of  the 
APPR/LAND  switch.  It  Is  used  to  control  the  flight  operations  for  non- 
precision approach  and  landing.  MPD-1  will  display  the  selected 
approach  plate  for  the  airport  and  runway.  MPD-2  will  display  the 
tailored  status;  the  HSD  wll  display  HSI  synt>ology  In  TACAN  steering  or 
i waypoint  map  In  Command  Nav  Steering;  the  HUD  and  VSD  will  display  the 

approach  and  landing  symbology;  and  the  IMFK  will  display  the  checklist 
^ and  tailored  specialist  functions.  After  the  pilot  selects  APPR/LAND 

• on  the  master  mode  panel,  the  descent  checklist  appears  on  the  IMFK. 

[ Upon  completion,  the  IMFK  displays  the  tailored  approach  and  landing 

I functions.  The  pilot  advances  to  the  before  landing  checklist  If 

I weight  Is  off  the  gear  by  pressing  the  CKLIST  key  on  the  IMFK.  After 

i completing  that  checklist,  the  IMFK  again  displays  the  tailored  func- 

I tions.  After  touchdown  (weight  on  gear)  the  pilot  may  select  display 

I of  the  post  landing  checklist.  After  completion,  the  IMFK  displays 

I the  de-arming  area  and  shutdown  checklist. 
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b.  Precision  Approach 

This  master  mode  Is  selected  by  the  pilot  depressing  the 
PREC/APPR  switch.  It  Is  used  when  flying  a precision  apprwch  i»1ng 
localizer  and  glide  slope.  Displays  and  Information 
the  selected  approach  plate  for  the  airport  and  runwj^;  tailored 

status  display;  HSD.  the  precision  approach  chart; 
precision  approach  and  landing  symbology;  ble 

specialist  functions.  Approach  and 

through' a tailored  mode  IMFK  key  as  In  APPR/LAND.  The  . . 

checklist  appears on  the  IMFK  when  selected  by  the  pilot  and  weight 

Is  on  the  gear. 
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8.0 


DAIS  SYSTEM  PROTOTYPE 


8.1  Introduction 

The  purpose  of  this  section  Is  to  describe  the  Digital 
Avionics  Information  System  (DAIS)  Prototype  which  was  a simulation 
system  used  to  Investigate  the  baseline  DAIS  design. 

The  DAIS  prototype  project  within  the  DAIS  program  was  under- 
taken In  order  to  demonstrate  the  baseline  DAIS  design  Including  the 
design  of  Its  hardware  and  software  elements.  The  particular  objectives 
of  the  DAIS  prototype  project  are  listed  below: 

• To  provide  a mechanism  for  Investigating 
the  DAIS  architecture  and  system  control 
procedures. 

a To  verify  the  DAIS  architecture  and  the 
design  of  the  DAIS  hardware  and  software 
elements. 

• To  Identify  DAIS  problem  areas  and  to 
feedback  problem  Information  Into  the 
ongoing  DAIS  effort. 

• To  gain  technical  and  management  experience 
which  Is  directly  transferable  to  the  DAIS 
development  effort. 
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8.2  DAIS  Prototype  Overview 

The  DAIS  Prototype  was  planned  to  be  a hardware/software 
simulation  of  DAIS.  This  required  that  the  hardware  architecture  and 
the  system  control  procedures  be  developed  according  to  DAIS  baseline 
specification.  However,  since  the  specific  performance  characteristics 
of  the  processors  in  the  system  were  not  of  critical  Importance,  the 
DEC  PDP  11/40  was  selected  as  the  DAIS  Prototype  processor.  These 
minicomputers  were  readily  available  in  the  laboratory  and  possessed 
the  required  I/O  features. 

Multiplex  Equipment  - Since  the  operation  of  the  data  bus 
and  the  system  protocol  for  comnuni cations  using  the  data  bus  are 
critical  to  the  system  control,  the  BCI  units  for  DAIS  Prototype  were 
designed  directly  to  the  DAIS  BCI  specification,  and  were  built  in 
breadboard  form.  As  problems  with  the  baseline  specification  were 
found  during  the  breadboard  development,  changes  to  the  baseline 
specification  were  made. 

As  in  DAIS,  the  breadboard  BCIs  were  used  to  connect  the 
PDP  11/40's  to  the  multiplex  data  bus.  An  RT/aircraft  equipment  . 
combination  was  simulated  by  connecting  an  additional  BCI  to  a separate 
PDP  11/40.  The  resulting  DAIS  Prototype  system  is  shown  in  Figure  41; 
coaparison  to  Figure  42  will  show  that  the  system  architecture  is 
identical  to  that  of  DAIS. 

Mission  Software  - As  previously  stated,  one  of  the  objec- 
tives of  the  DAIS  Prototype  was  to  Investigate  the  DAIS  executive 
software  baseline  design.  Therefore,  an  existing  DAIS  top  level 
design  specification  for  the  DAIS  executive  software  was  used  as  the 
prototype  executive  baseline.  For  DAIS,  the  executive  software  will 
be  developed  in  JOVIAL  J73/I.  Since  a JOVIAL  compiler  was  not  avail- 
able for  the  PDP  11/40,  the  prototype  executive  was  written  in 
asseably  language  using  a set  of  macro  constructs  and  a top  down 
structured  programming  approach.  This  was  done  to  Insure  transfer-  ^ 

ability  of  the  executive  to  DAIS. 

The  application  software  developed  for  the  DAIS  Prototype 
was  a set  of  application  stubs  developed  specifically  to  request 
executive  services,  to  process  received  bus  data,  and  to  provide  data 
for  output  on  the  bus. 
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DAIS  Prototype  Operation  - To  conduct  simulation  and  testing 
activities  on  the  DAIS  prototype  required  a means  of  test  control  and 
monitoring.  This  capability  was  provided  by  a PDP  11/40  processor 
referred  to  as  the  facility  processor.  Reference  to  Figure  42  shows 
that  the  facility  processor  is  the  same  processor  used  to  simulate 
the  RT.  The  facility  processor  interfaces  with  the  DAIS  prototype 
via  special  control  and  monitor  hardware  units  and  has  a DMA 
interface  with  the  DEC  Systero-10.  A block  diagram  is  shown  in  Figure 
42. 

An  Interrupt  control  device  called  a Super  Control  and  Dis- 
play Unit  (SCADU)  was  developed  to  interface  each  system  processor  to 
the  facility.  This  device  gives  the  facility  the  capability  to  control 
the  operation  of  the  system.  The  control  is  implemented  with  a set  of 
System  Test  and  Evaluation  (ST&E)  software  in  each  system  processor 
which  interacts  with  the  facility  through  the  SCADU.  The  ST&E  software 
in  the  system  processors  and  the  software  in  the  facility  processor, 
communicating  through  the  SCADU,  gives  the  operator  the  capability  to 
control  test  operations. 

A 4K  four-port  buffer  memory,  accessible  to  all  three  system 
processors  and  to  the  facility,  was  developed  in  order  to  provide  a 
test  data  collection  path.  Each  system  processor  was  assigned  an  area 
of  the  shared  memory  with  two  data  collection  queues  in  each  area. 
Whenever  an  action  requiring  test  data  to  be  collected  occurs  in  a 
system  processor,  the  ST&E  software  in  that  processor  places  the  test 
data  in  the  appropriate  data  queue  in  the  shared  memory.  Whenever  a 
queue  becomes  full,  the  facility  is  notified,  and  the  system  processor 
will  use  the  other  queue.  The  facility  collected  the  data  from  the 
full  queue,  and  then  released  that  queue  for  use.  The  collected  test 
data  was  formatted  into  a record,  and  passed  to  the  DEC  System-10  for 
recording  on  the  test  data  file. 

A bus  monitor  device  was  developed  to  collect  test  data 
about  the  operation  on  the  data  bus.  This  device  monitors  the  data 
buses,  and  records  the  bus  messages  and  the  time  of  occurrence. 

Whenever  a full  block  of  data  bus  traffic  has  been  recorded,  the 
facility  software  formats  the  collected  test  data  as  a record,  and 
passes  it  to  the  DEC  System-10  for  recording  on  the  test  data  file. 

The  facility  software  also  had  the  capability  to  collect  bus  message 
data  addressed  to  the  facility's  BCI. 

The  facility  was  interfaced  to  the  DEC  System-10  through  a 
DMA  channel.  The  facility  used  this  link  to  pass  test  data  records 
to  the  DEC  System-10  for  recording  on  the  test  data  file.  A test 
data  collection  routine  ran  on  the  DEC  System-10  in  real  time, 
locked  in  core.  This  routine  accepted  each  test  data  record  and  wrote 
it  onto  the  test  data  file.  This  routine  had  a user  interface 
which  allows  the  operator  to  name  the  test  data  file  at  test  initial- 
ization. 
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When  a test  data  file  was  generated  at  the  end  of  a test, 
the  test  data  analysis  program  ran,  using  that  test  data  file  as  w 
input.  The  operator  examined  the  test  data,  printed  specific  portions 
o/the  data  file,  ran  analysis  routines  on  specific  test  PJJ®" 
meterst  printed  the  results  of  the  analysis,  and  printed  the  difference 
between  the  test  data  file  and  otter  test  data  files. 


8.3  DAIS  Prototype  Integration  and  Test 

There  were  three  phases  of  activity  associated  with  the  DAIS 
Prototype  project.  During  phase  A,  the  different  hardware  peices 
were  tested,  design  specifications  were  written  for  the  software 
elements,  and  requirements  were  formulated  for  test  control  and  moni- 
toring. Phase  B saw  the  integration  of  the  hardware  and  software 
resulting  in  an  operational  prototype.  During  phase  C a detailed 
evaluation  of  the  DAIS  prototype  executive  was  performed  with  emphasis 
on  measurement  of  the  executive  overhead. 

Phase  A - The  hardware  unit  testing  completed  during  phase  A 
required  the  generation  of  special  test  software  and,  in  most  cases, 
required  the  integration  of  two  or  more  pieces  of  the  hardware.  This 
not  only  assured  the  integrity  of  each  hardware  unit,  but  also  exer- 
cised many  of  the  electrical/functional  connections  between  units. 

While  testing  of  the  hardware  units  was  being  performed,  the 
detailed  requirements  specifications  for  the  executive  was  prepared 
using  as  a baseline  existing  top  level  specifications  for  the  DAIS 
executive.  The  design  of  the  executive  was  extended  to  incorporate 
features  not  covered  in  the  existing  specifications,  especially  in  the 
area  of  system  error  and  failure  handling.  A programming  standards 
manual  was  written  specifying  development  of  the  executive  in  a top 
down  manner  using  the  DEC  MACRO  assembler.  The  allowable  program 
constructs  were  written  as  macros  and  added  to  the  PDP  11/40  system 
macro  library. 

Also  during  phase  A,  requirements  for  the  facility  software 
and  the  ST&E  software  related  to  test  control  and  monitoring  were 
formulated.  These  requirements  can  be  divided  into  four  areas:  test 
setup  and  control,  data  collection,  error/failure  simulation,  and  post 
test  analysis. 

The  test  setup  and  control  functions  allowed  the  test  operator 
to  preplan  the  test,  specifying  test  length,  bus  data  collection 
requirements,  error/failure  simulation  actions,  and  minor  cycle  "freeze" 
points  at  which  the  test  is  to  be  stopped  for  investigative  purposes. 
Interactive  commands  provided  the  operator  with  capabilities  to  continue 
from  freeze  points,  to  single  step  the  system  on  a minor  frame  (8  msec) 
basis,  and  to  stop  the  test. 

The  data  collection  function  provided  for  collection  of  test 
data  from  several  sources  and  on  line  transfer  of  the  data  to  a file 
maintained  on  the  DEC  System-10.  The  sources  from  which  data  were 
collected  are:  1)  the  bus  monitor  unit,  which  was  progranmed  to 
collect  all  bus  data  for  a short  time  period  or  selected  bus  data  for 
longer  time  periods;  2)  the  facility's  BCI,  which  process  all  bus 
messages  addressed  to  the  facility;  and  3)  the  four-port  buffer  memory 
into  which  test  data  was  stored  by  the  ST&E  software  contained  in  the 
system  processors.  Refer  to  Figure  42  for  the  placement  of  these 
hardware  units  in  the  DAIS  Prototype. 
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Error/failure  simulation  was  performed  by  controlling  the  BCIs 
connected  to  the  system  processors,  and  the  facility's  BCI.  Under 
operator  control,  either  preplanned  or  interactive,  any  of  these  three 
units  could  be  made  to  enter  either  a non- responding  or  busy  state,  or  to 
simulate  a total  failure.  Either  of  the  first  two  states  could  be  for  a 
specified  time  or  for  the  remaining  test  time. 

The  post  test  analysis  capability  provided  by  a DEC  System-10 
routine,  allowed  the  test  operator  to  dump  all  or  specific  sections  of 
the  data  collected,  to  display  portions  of  the  data  on  a CRT,  and  to 
perform  other  analysis  functions  on  the  test  data. 

Phase  B - During  this  phase,  the  hardware,  the  facility 
software,  the  SY&E  software,  the  DAIS  Prototype  executive,  and  the  appli- 
cation software  stubs  were  integrated  into  a working  system.  Because  of 
the  number  of  pieces  of  hardware  and  software  involved,  a five  step 
process  was  used  to  perform  integration.  Figure  42  depicts  the  harch^are 
configuration  for  each  step. 

The  objective  of  step  1 of  phase  B was  to  exercise  the  test 
control  and  monitor  interfaces  between  the  facility  processor  and  one 
system  processor,  and  to  exercise  some  of  the  local  executive  func- 
tions. This  required  that  the  facility  software  and  the  ST&E  software 
be  operational.  Portions  of  the  executive  which  were  tested  were  the 
local  executive  services  of  data  read  and  write,  and  tasking  control. 

Note  that  communication  via  the  multiplex  data  bus  was  not  tested  during 
this  step.  Application  tasks  were  simulated  by  stubs  which  were  pro- 
grammed to  request  executive  services.  Testing  was  performed,  and 
test  data  was  collected,  in  real  time,  from  the  executive.  The  test 
data  was  transferred  via  the  multiport  buffer  memory  to  the  facility 
processor  and  then  to  the  DEC  System-10.  The  data  collected  was 
examined  to  verify  correct  operation  of  the  hardware  and  software. 

In  step  2,  the  multiplex  data  bus,  the  facility  BCI,  and  the 
system  processor  BCI  were  added  to  the  system.  This  provided  a conmun- 
ication  path  between  the  system  processor  and  an  RT,  as  simulated  by 
the  facility  processor.  Those  portions  of  the  local  executive  which 
control  synchronous  bus  communications  were  added  to  the  step  1 exec- 
utive. The  capability  to  transmit  and  receive  data  in  response  to 
romnands  from  the  system  processor  was  added  to  the  facility  software. 
Application  stubs  were  used  to  request  executive  services,  and  test 
data  was  collected  and  written  into  multiport  buffer  memory  by  the 
ST&E  software.  Post  test  analysis  was  performed  on  the  collected  data 
to  verify  correct  syn^ronous  bus  conmuni cations. 

The  second  system  processor  was  added  in  step  3,  holding  all 
the  other  hardware  and  software  system  variables  constant.  This  con- 
figured the  system  to  test  synchronous  bus  communications  between  two 
system  processors  and  a simulated  RT.  System  processor  1 was  desig- 
nated the  master  processor,  and  thus  contained  the  master  executive 


as  well  as  a local  executive.  The  synchronous  bus  control  tables  in 
the  master  processor  were  modified  to  control  the  transmission  of 
messages  between  three  terminals  instead  of  the  two  terminals  used  in 
step  2. 

Step  3 testing  included  making  overhead  measurements  of  all 
the  executive  services  and  the  executive  tasks  associated  with  synch- 
ronous bus  communications.  These  measurements  showed  the  need  for 
changes  in  the  executive  to  reduce  overhead.  Since  the  executive  was 
table  driven,  many  of  the  changes  were  as  simple  as  reordering  of 
tables;  for  example,  using  unpacked  tables  to  reduce  the  table  decode 
time.  On  the  other  hand,  the  method  of  setting  up  for  reception/ 
transmission  of  synchronous  messages  was  changed  considerably. 

The  step  4 hardware  configuration  was  identical  to  that  of 
step  3.  The  capability  to  transmit  asynchronous  messages  between 
system  processors  and  between  the  system  processors  and  the  RT  was 
incorporated  into  the  executive.  Testing  was  performed,  and  test 
data  collected  and  analyzed  to  prove  the  correct  operation  of  asynch- 
ronous message  transmission.  At  completion  of  this  step,  the  executive 
contained  all  its  capabilities  except  that  of  error/failure  recovery. 

In  step  5,  the  Bus  Monitor  Unit  (BMU)  which  provides  for 
monitoring  of  message  data  on  the  bus  was  added  to  the  system.  In  the 
software  area,  step  5 was  a significant  change  since  it  saw  the  addi- 
tion of  the  error/failure  recovery  capability.  Error  recovery  involves 
repeating  of  the  bus  message  over  the  same  or  a redundant  path. 

Recovery  from  equipment  failures  requires  the  identification  of  the 
failure  and  the  use  of  a redundant  path  for  transmission  of  the  message, 
or  the  isolation  of  the  failed  equipment  when  the  failure  involves 
both  redundant  elements.  The  DAIS  error/failure  handling  approach  was 
used  as  a baseline  for  the  equivalent  DAIS  Prototype  capability. 

As  part  of  step  5,  the  executive  was  also  updated  to  incor- 
porate the  efficiency  related  changes  identified  during  step  3.  Testing 
was  then  performed  to  verify  the  error/ failure  recovery  capability  and 
to  insure  that  the  efficiency  related  changes  were  made  properly.  In 
testing  the  error/failu»e  capability  of  the  executive,  extensive  use 
was  made  of  the  facility's  capability  to  simulate  transient  and  per- 
manent failures  in  the  three  BCIs. 

Phase  C - The  objective  of  this  phase  was  a detailed  evalua- 
tion of  the  executive.  As  part  of  the  DAIS  project  itself,  a series  of 
close  air  support  (CAS)  missions  are  planned.  A detailed  analysis  of 
one  of  the  CAS  missions  has  been  performed  to  determine  the  expected 
bus  loading  and  the  expected  load  on  the  master  and  local  executive. 

For  phase  C,  the  number  of  simulated  tasks  in  each  system  processor 
was  as  expected  in  the  CAS  mission,  the  simulated  application  task 
was  programmed  to  request  executive  service  at  the  rate  expected,  and 
the  expected  number  of  synchronous  and  asynchronous  bus  messages  was 
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transmitted.  Testing  was  performed  to  obtain  overhead  measurements 
of  executive  bus  message  control  tasks,  executive  control  of  application 
tasks,  and  all  executive  services  provided  to  the  application  software. 
The  Information  obtained  was  used  to  Identify  executive  problem  areas 
and  to  approximate  the  overhead  of  the  DAIS  executive. 
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8.4 


DAIS  Prototype  Conclusions 


The  DAIS  Prototype  project  was  organized  to  provide  transfer 
of  Information  and  experience  to  the  DAIS.  DAIS  core  elements  speci- 
fications were  used  In  development  of  the  equivalent  DAIS  Prototype 
core  elements.  Key  personnel  were  assigned  similar  areas  of  respon- 
sibility on  both  projects;  and  "Design  To"  and  "As  Designed"  specifi- 
cations were  published  for  the  hardware  and  software  elements.  Much 
of  the  prototype  project  experience  was  directly  transferable  to  the 
DAIS  effort  resulting  In  problem  corrections  and  Improved  designs  for 
the  DAIS  system  elements.  Some  of  the  more  Important  benefits  were: 

1.  Hardware  Changes  - In  the  process  of  Inter- 
facing the  executive  software  to  the  BCIs, 
problem  areas  of  the  BCI  were  uncovered, 
and  other  areas  where  improvements  could  be 
made  were  Identified.  Consideration  of  the 
BCI  brought  about  a reconsideration  of  the 
RT  design  where  a message  transfer  problem 
was  discovered  and  solved. 

2.  Executive  Design  - The  DAIS  Prototype  exec- 
utive, plus  recommended  changes  resulting 
from  the  evaluation  of  the  executive,  became 
the  baseline  for  the  DAIS  executive. 

3.  System  Control  Procedures  - Development  of 
the  DAIS  Prototype  executive,  especially  In 
the  areas  of  asynchronous  communications, 
contributed  to  development  of  the  DAIS 
system  control  procedures.  Likewise,  Incor- 
poration of  the  error/ failure  handling 
capability  Into  the  prototype  executive 
provided  an  evaluation  of  the  DAIS  system 
control  procedures  In  a time  frame  which 
allowed  for  modifications. 

Benefits  also  resulted  from  prototype  activities  not  directly 
related  to  evaluation  of  core  elements  and  system  operation.  These  are 
summarized  below: 

1.  In  developing  the  executive,  a top  down, 
structured  programming  methodology  applica- 
ble to  real  time  assembly  language  programming 
was  developed  and  successfully  used.  This 
methodology  and  experience  will  prove  useful 
In  development  of  the  support  software  for  the 
DAIS. 

2.  The  techniques  developed  for  test  control  and 
monitoring  will  contribute  to  the  development  of 
similar  capabilities  for  the  DAIS  test  system. 

-154- 


9.0 


C0t<CLUSI0N  AT^D  RECOMMENDATIONS 


The  DAIS  program  successfully  developed  and  tested  the  DAIS 
architecture  using  representative  core  elements,  thus  demonstrating  a 
solution  to  the  problem  of  proliferation  and  nonstandardization  of 
aircraft  avionics.  The  key  results  of  the  program  Included: 

f An  architecture  which  Is  adaptable  to 
various  avionic  applications. 

e Demonstrated  multiple  configuration  of  the 
architecture  without  modifying  the  architec- 
ture - e.g.  open  ended  system  capability 

a Technology  for  the  standardization  of  coimion, 
Interchangeable,  and  shared  system  core 
elements  and  support  elements. 

a Set  of  verified  specifications  for  the  DAIS 
architecture,  core  elements,  and  support 
elements.* 

The  results  of  the  DAIS  program  will  permit  the  Air  Force  to  assume 
the  Initiative  In  the  specification  of  avionic  systems  for  acquisition 
of  new  or  retrofit  weapon  systems.  This  will  result  in  significant 
payoffs  and  benefits  for  the  acquisition,  operation  and  logistics  of 
weapon  systems  as  summarized  below: 

a.  Acquisition 

a Reduced  proliferation  of  system  and  subsystems, 
and  associated  support  elements. 

a Validated  systems  and  hardware/software  specifi- 
cation 

a Procurement  of  interchangeable  subsystem  elements 
a Economies  in  production 

I 

b.  Operational  Benefits 

a Increased  ability  to  maintain  avionics  systems  in 
an  operational  ready  state. 

a Ability  to  respond  to  new  or  changing  threats. 

a Increased  maturity  of  common  elements. 

a Increased  system  availability. 


The  DAIS  Specifications  are  identified  in  MA  100  100,  DAIS  Document 
Description  Manual. 


c.  Logistics  Benefits  ' 

• Family  of  interchangeable  subsystems  and 
associated  support  elements 

• Common  support  tools  (software  and  hardware) 

• Reduced  retrofit  costs  by  dictating  standard 
interfaces,  dictating  the  use  of  common  and 
shared  system  elements  and  programming  stan- 
dards and  language 

• Reduced  training  and  maintenance  costs  for 
common  elements 

• On-board  tests  to  reduce  maintenance  costs. 

The  net  results  will  be  reduced  life  cycle  costs  of  avionics  (e.g. 
reduced  total  system  costs),  and  improved  availability  (e.g.  increased 
sortie  generation  rate  and  mission  readiness)  as  well  as  ability  to 
adapt  to  new  threats. 

The  DAIS  program  has  demonstrated  that  architecture,  inter- 
face and  core  element  standards  can  form  the  building  blocks  for  the 
configuration  of  avionic  systems  which  will  avoid  proliferation  of 
development  programs  and  their  costs,  and  result  in  significant  reduc- 
tions in  support  and  maintenance  costs.  Significant  benefits  can  be 
achieved  by  the  Air  Force  in  the  continued  promotion  and  development 
of  these  DAIS  concepts.  The  task  that  now  needs  to  be  accomplished  is 
the  transition  of  DAIS  and  related  technology  in  the  form  of  standards 
which  can  be  applied  to  new  aircraft  avionics  developments  and  retrofit 
or  upgrade  programs. 
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